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...
Related
I have developed a cucumber based selenium automation framework and have used Page Object with Page Factory as the design pattern for it.
Below are different components of my automation framework :
Page Objects.
POJOs
sharedutilities
Feature Files
Config file
Expected Data folder
Extent config.xml
chromedriver.exe
Reports folder
I am not entirely satisfied with the way I have arranged these components inside maven project. There are multiple source folder for Maven like src/test/java, src/main/java, src/test/resources, src/main/resources, are there some standard set of guidelines on what to put inside these 4 folders depending on the components which I have mentioned above ?
General guidelines:
src/main/java contains your application code (.java files)
src/main/resources contains any non-code files that go with your application. for instance property files or config files for your application (if they are not Java config files, like your config.xml).
src/test/java contains any test code (.java files) for your application. If you mirror your package structure from src/main/java testing frameworks like Junit can automatically find the right classes to test without having to specify imports for them. In the case of Cucumber, this is where your step definitions go, as well as any other code that helps you perform your Cucumber tests (like the Page Objects in your example).
src/test/resources contains any non code files that go with your tests. In the case of Cucumber, this is where the feature files go. If you have a separate test config.xml that would go here.
If you have only test code, you might not have a src/main folder. I'd recommend locating your test code in the same repository as the system you're going to test, as this will make it easier to get fast feedback.
Regarding your question:
Page Objects -> src/test/java
POJOs - depending on whether they are application POJOs or test POJOs -> src/main/java or src/test/java respectively
sharedutilities - asusming this is code to help your tests -> src/test/java
Feature Files -> src/test/resources
Config file -> depends on whether this is for the application or test, and whether its code or xml.
Expected Data folder - not sure what you mean. Test files (like .json or something) might go in src/test/resources
Extent config.xml - probably src/test/resources
chromedriver.exe - might go in your root directory. (I might recommend against including .exe in your project; how are you going to deal with different OS?)
Reports folder -> would probably go to a target folder?
Hope this helps.
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.
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 have a solution wich consists of main application MainProject and several plugin projects Plugin1, Plugin2 etc. Each of them is build in a separate project within Visual Studio.
For building the soution, I want all files of the plugins to be copied into the main application's output directory. But I don't want MainProject.exe to contain explicit references to the plugin dlls (they are loaded dynamically). Therefore defining project references for MainProjectdoesn't work.
I could use a post-build-step copying the files "manually" (as described in C# - Copy dlls to the exe output directory when using dependency injection with no references?), but since there might be multiple files for each plugin and they also change from time to time this solution is rather tedious to maintain (especially since I do have different build configurations, each of them producing different files). Also I would like to easily select, which plugins should be copied for a certain build.
What would be the best way, possibly involving custom MSBuild configuration changes, to do this?
See this link: http://msdn.microsoft.com/en-us/library/bb629394%28v=vs.100%29.aspx
When invoking MSBuild on the main project, if you could pass something on the lines of:
msbuild /p:CustomBeforeMicrosoftCommonTargets=[your custom msbuild file];PluginList=PathToPlugin1.csproj,PathToPlugin2.csproj
In your custom msbuild file, a target such as GatherInfo will get you the paths to output files of each plugin project. See this question for a sample: https://stackoverflow.com/questions/23346782/how-to-identify-files-needed-to-build-a-wix-project
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.