I am trying to make a standard class library in vs11 with more available classes than a library with metro offers (for example System.Console) and I cannot figure out how to create unit tests for it. I have tried looking through Google an nothing works. I actually had to go into vs2010, create the project, add the tests, and reopen in vs11. Was this functionality removed (which I doubt. I know unit testing is available)?
I have seen the unit test library project type, but it does not seem to support this type of library. What are my options?
Not sure what exactly you asking but If I understood you correctly, you want to create a standard class library and a standard Unit test project for the class library? Did you check the project templates under "Test". In here you can create a Unit Test project for the class library. You do not have to go to VS2010 and create a Test project then open it in VS. Apologies if that's not what you asking for.
As Raj said, just create a standard class library, reference the test framework you want to write tests in and then add test code as per usual.
For MSTest you need to add a reference to Microsoft.VisualStudio.QualityTools.UnitTestFramework and for the others use NuGet.
I have a blog post showing how the new unit test explorer works that might be helpful
Related
I am trying to test a dll that was created in C++, specifically to test certain functions. A few search results gave the solution as testing in visual studio by creating a simple unit test and referencing the dll as a project. But the solution is not very clear to me and there is no way to add the dll to the unit test project, as the only options are projects, solution, shared projects. I don't even see the browse button.
Does anyone have a solution or could you explain this solution provided here? I just want to be able to call the dll function, from a C++ class or project to test the input & output.
test dll
It is pretty straight forward actually.
In the DLL project you can create a native Unit test project and write test methods.
Here is the link to clear steps with screenshots - https://learn.microsoft.com/en-us/visualstudio/test/writing-unit-tests-for-c-cpp.
Edit: I am assuming you have access to DLL code.
I decided to add tests for my library.
The problem is that most (all?) of the test frameworks are using the same approach: build an executable file which contains code to be tested, tests and framework.
But what if I have a library which is heavy (a lot of code inside) but has only a few public functions / classes? In such situation I cannot test it well until:
I export all symbols from library
I build executable file with all library sources included
Ad. 1: it's not nice
Ad. 2: when I work with visual studio it would require me to synchronize library project with 'test' executrable project (adding/removing files etc). So it also doesn't look nice for me.
Are there any other approaches?
If you can do 2) so you should be able to reorganize your file/folder/project like;
1) a static library project containing all the internal function and object
2) a test project using any framework (there is a lot of framework with pro&con for each, my advice if you are beginner select the integrated solution or a simple framework). that test project must DEPEND (add dependcy in solution explorer menu) of the static lib. So you can add test on your internal implemtation
now the external api.
3) your old DLL project keep only the public API definition and implementation. And DEPEND of the static lib.
4) add a test project for your public api
No need to synchronize project and compile code twice, and with effort you could test more than just the external api without any internal code change.
Generally, test-driven programming works well with many and small "units". Having a few and bloated "units" makes the testing phase untolerable!
The only viable solution I see is to isolate specific parts of the code and then step into them with the debugger. Having many private functions usually leads to the aforementioned issue and since you can't access them directly during unit tests, you should really consider using the debugger for the non-obvious.
I've been studying C++ for a while, but this is the first time I'm into a C++ project (a pet configuration parser library). I'm using the Google C++ Testing Framework to test this. But I don't know if I'm doing it right.
Currently, I've ripped off some parts of this Google test library and put it into my projects Test/googletest directory. It works OK, but I wonder if this is how I'm supposed to do this. I'm including the source code of the testing framework in my project and it will be released with my code. This makes me feel uncomfortable.
I wandered through some C++ projects on GitHub, trying to see how other people deal with this. Some have custom framework-lets, and most solve the whole problem with not testing the code at all.
I wonder if I'm taking this right, or otherwise how can I adopt a testing method that will both keep the framework out of my source tree and let me release my code with tests buildable and executable by the user?
Concerning your build, you're doing it right. The gtest readme explicitly states that building gtest (you can pack a libgtest.a from the two object files) along with your project is the prefered way to do it.
Concerning the distribution:
Ideally, you could have your build tool (make, CMake, etc) check out / fetch the required gtest version from its own repository. But I don't think there is much harm if you add an "external" folder to your project and include stuff like gtest in your own repository.
I want to use Boost Test to unit test my code in Visual Studio 2010. I've downloaded and built the latest version of the library.
I've read a lot on the subject here and elsewhere on the internet and people seem to suggest having a second project within your solution exlusively for your tests.
Fine, sounds good. I'm having trouble actually setting this up however. I've yet to find a clear explanation of the best way to set this up.
Do I need to use a Project Reference to make my unit test project reference my main project?
If so, do I still need to add the Include & Source directories of my main project in the properties of my unit test project? If so, what's the advantage of using the Project Reference in the first place?
Do I have to have my main project output a library for my unit test project to link in? Again, I thought that Project References would make this unnecessary but it seems I don't really understand the Project References.
If at all possible could I get a very idiot proof, step by step procedure for setting up a Boost Test unit test project alongside a main project in VS2010?
Would I be better off going with the method laid out here (one project, different configurations to build tests or actual project exe):
http://blog.yastrebkov.com/2010/07/boost-test-setup-and-usage.html
Many thanks,
There is no magic behind setting up a Boost.Test project. Maybe because it's a regular C++ (executable) project in no way different from a "normal" application. This is what I do:
Create a new C++ project. I always choose Win32 Executable with precompiled headers. I have a naming convention, that all test projects using Boost.Test start with "tests.boost.testee_name..."
In "stdafx.h", add the include for <boost/unit_test.hpp> and define the BOOST_TEST_MODULE (I always choose the project name). Also, add all other includes for external components this project requires, e.g. other boost libraries, stl headers etc. This results in considerably faster compilation times.
The testee must be a library (dynamic or static). So "add reference" to all required dependencies. You can of course test header-only libraries, in that case do not add references.
Add source files to your test project, according to Boost.Test manual. The convention I enforce is one BOOST_FIXTURE_TEST_SUITE per file.
For convenience, I have a custom property sheet tailored for boost unit test, which I add to each boost test project. Among others it contains a post-build event, which runs the tests.
I have to add that, lately, I switched to MSTest with Visual Studio 2012 which allows a more comfortable way to manage the tests and test results. Nevertheless, for the most important parts of the software, I am still writing boost tests in order to ensure correctness with older toolsets and potentially other platforms.
Cheers,
Paul
I would like to write some test code for a C++ class. Because the class is part of an application but not a part of library I would like to know which unit test framework does not require building project as a library in order to run unit test code?
I tried the WinUnit but it seems only can test a library.
Any testing framework I know would allow that. It is an issue with the setting for your build environment, not the testing framework itself.
The easiest way to maintain it is to set up a library for your application code though.
I never used WinUnit, but I have used CppUnit and GoogleTest within VisualStudio projects where the code under test was not in a library, but the implementation files for the SUT were referenced (included) in the unit test project and it worked out.
Executables don't export symbols by default. You need to enable that with -Wl,--export-dynamic then link against the produced executable as though it was a library. This also means you need to do proper import/export on the classes you want to use etc.