I have one file which reference I have added in xcode main project target and test case both.
This file reference needs to be added to main project only when test cases are running.
I don't want to include it when I create main project build since this file is for testing purpose only.
What is the best way to remove reference from main project when test cases are not running?
I have resolved my issue by using Exclude files setting from xcode's build setting.
I have added mock file reference to both app and test target.
Then for release and AppStore build configuration I have excluded mock file so that it doesn't any extra size in app store build.
Since test cases run only in debug mode. This is safe solution.
Related
I am trying to make use of modules and gradle subprojects and either receive compile time errors or complaints from IntelliJ.
My project structure is as follows:
Root
- settings.gradle
- core
- build.gradle
- desktop
- build.gradle
- src/main/java/module-info.java
The desktop build.gradle file as a requirement on core as:
dependencies {
implementation project(":core")
}
There is no reference to the "core" project in the module-info.java files.
In this configuration, IntelliJ doesn't like usage of classes from the "core" project in the "desktop" project (I see a lot of red), but running gradlew.bat desktop:run works with no issues. Bug with IntelliJ? I am using microsoft's openjdk, but hopefully that doesn't matter.
My best attempt to fix this, was to add a module-info.java file to the core project as well and reference the core project in the desktop project's module-info.java file. Unfortunately this configuration, while making IntelliJ happy, renders me unable to run the desktop from command line anymore. I get errors about the core project being unable to find required modules that are the exact same as the required modules I pull in for the desktop module. I think this might be an error on my part, but I'm not sure how or what to do to fix it.
Would appreciate any insight.
P.S. Of these issues, I think I would prefer to get IntelliJ working with the first setup, because I intend to have this core library be shared between the desktop project and an android project, and while I haven't looked into it yet, I am not sure Android supports new java modules?
I think terminal should be the first priority. If your original setup made it compiled successfully under terminal, then there is no problem in your project. Do not add extra files for just making the IDE happy.
There's still something you can do. The first step is compiling your project successfully under terminal. This step downloads all the necessary dependencies before IntelliJ, reducing the problem scope to IntelliJ's linking and indexing. Then there are some options:
In the Gradle tool window, click the top-left button Refresh all Gradle projects.
Delete all the .idea folders in your project. Then open the root folder of your project via UI or CLI.
Click the invalidate caches/restart in the main menu.
You can also also create a new Gradle multi-module project with command gradle init, and open it with IntelliJ. It should be analyzed by IntelliJ normally. Then you can compare its project structure with yours. Maybe there's something different.
Hope these steps could help you.
dll project for which i want to create unit tests.
In order to run unit tests i need my test project to compile all dependencies and i don't want to add my cpp files to test project.
The solution is to add lib in references but i have no clue how should i compile my project as both dll and as lib. Is this even possible ? I suggest that could be easy with naked cmake/make.
What i could do is create another project with same files and build it as a .lib. I think this solution is very primitive and it will require me to add .cpp files to projects twice if i ever want to add something new. I would prefer a solution in which i could have only one project in solution and have it build .dll (a main component) and a .lib for UT project reference.
I know i could also make UT load my .dll and have that kind of dynamic linkage, but that would make it harder due the need of creation of dll wrapper to access those functions.
I also considered using batch build and have custom build configuration. But this will require me to batch build every time i want to run UTs. I'd rather have it chose automaticaly. Maybe if i set UT project to be build under custom configuration the dependency will also be build with custom config?
Does Visual Studio 2015 bring any simple solution to this problem?
I'm quite new to QtCreator, so perhaps I left my heart in eclipse-ville, but I can't for the life of me understand how I should be setting up a project hierarchy in QtCreator. I understand there is an option to create a kind of root project and then from there add sub-projects to it, which makes sense but it leaves me wondering whether or not this is necessary at the time of creating the project, e.g. can I just create a library in one project and reference it later by another project?
I've tried setting up a blanket type of project by creating a new subdirs project and then adding the main program as a subproject, but then how should I add my library project?
Ideally, I'd like to create one project as the main application and reference another project as a library. Help?
The documentation of Qt Creator contains two sections that may help you find the answers to your questions:
Adding Subprojects to Projects
Adding Libraries to Projects
EDIT:
You can find a really simple sample project here: QtSymbianDllExample. "It is intended to demonstrate how to create and use a DLL with Qt on the Symbian platform". It is a sample for Symbian development but that is irrelevant now, I do not have a Symbian phone. What is important is that it contains a root project (QtSymbianDllExample\qtssymbiandllexample.pro) and two subprojects (QtSymbianDllExample\qtenginedll\qtenginedll.pro, QtSymbianDllExample\testui_simpledllengine\testui_simpledllengine.pro) which you can examine and compare to you projects. I have checked that I can build the root project by doing the following steps:
Download and install the Windows Offline Installer from http://www.qt.io/download/
Download and extract QtSymbianDllExample.zip
Run Qt Creator
File / Open File or Project... Select qtssymbiandllexample.pro
Build / Run qmake
Build / Build project "qtsymbiandllexample"
I am using QT Creator and want to run my unit tests in a separate project. How do I reference the classes in the main project from my test project?
I realise this is an old question, but here are a few steps to make this easy:
Move most of your config from main_project.pro file to a main_project.pri file.
Use relative paths, relative to you *.pri or *.pro files, using $$PWD/path/to/file syntax where $$PWD is your *.pri or *.pro file location.
Include *.pri file using include($$PWD/main_project.pri)
Create a test project in your main_project folder.
In test/test.pro, add the line include($$PWD/../main_project.pri) to import the relevant configuration from you main_project.
I can add more details if there is some interest.
Once the basic setup is working, it's quite handy as you can create a separate project for each module you want to test plus global test_suite that run all the other tests. If you find that many test projects share some configuration, you can create a separate common.pri file in test/common to include in all your test projects.
Once, that's in place, it quite easy to generate a small script to automatically create a test project when in order to test a new module, resulting quite an efficient testing workflow...
I have a unit test which depends on some code that uses MEF. When I run the test, MEF (I believe) MEF tries to load all dependent DLLs for all the DLLs in the unit test's executing directory.
The problem is that VS2010 for some reason isn't copying all the DLLs from the /bin/debug directory to the unit test's executing directory, and I don't know why. Here's an example:
Unit test is complaining is can't load assembly A, so I include project B which assembly A has as a dependency. In the /bin/debug folder for the unit test project, all the DLLs are in there, but when I look at the unit test's executing directory, assembly A isn't there.
I could start adding DLLs as refs to the unit test project one by one, but I feel like I should have to.
Thoughts?
thanks,
Mark
Maybe the DeploymentItem attribute can help, http://msdn.microsoft.com/en-us/library/ms182475.aspx:
For the parameter of the DeploymentItem attribute, specify the folder
or file that you want to deploy for this test. You can use either an
absolute path or a relative path. Relative paths are relative to the
RelativePathRoot setting found in the .testrunconfig file.
[TestMethod]
[DeploymentItem("MyTestProject\\testdatasource.mdb")]
public void TestMethod1()
{
// TODO: Add test logic here
}
You can add the project as a reference and it will sort it out.
Right click add ref project tab.
Dont ref the dll itself in teh bin\debug folder.
As test projects are simply extensions of the production code, it's not uncommon to share the same dependencies. In some cases, excluding a dependency may compile fine but will fail when the code under test tries to load a missing dependency at runtime (as you've discovered). If your tests however have to use a dependency in the test code, you'll find that you won't be able to compile without referencing that dependency.
Also keep in mind that when you execute a TestRun with MSTest, it's not the compilation process that copies the assemblies -- there's a post compilation step that copies the dependencies for the tests to a specialized "test run" folder, typically under TestResults. Visual Studio supports a feature called "Test Deployment" that can copy additional test data, etc to the test run.
The other element at play here may be the dynamic composition nature of MEF. One of the key benefits of MEF is that it follows a plugin model that dynamically loads assemblies into your application at runtime: simply drop in new assemblies and MEF will pick them up. As such, it's common that the design of the main application will not have direct references to these dynamically loaded assemblies. If you're using MEF in your tests to dynamically load tests, these tests must be copied (using Test Deployment) or referenced as part of the test project.