Hello all,
I'm pitching for a 'contract' and part of technical test involves me writing unit tests for a C++ application. I barely have any experience with unit tests.
Say we have a simple RESTful server that responds in Json and a Wt web interface. What kind of tests am I expected to come up with ?
You can attempt to mock out the server response and then use that mock to assure it was called correctly and then feed your client a synthetic response. You can test the JSON response parsing completely independently of anything else.
I use Catch as my C++ testing framework but it doesn't support mocking. GTest includes mocking but needs to actually be built and linked against to function properly.
In general unit testing is writing test cases for code that you write, that largely ignores external things such as API usage, databases, networking etc. Mostly those things are mocked. Your tests should give ample coverage to all branches within code, and also check that exceptions are caught and dealt with correctly. Testing is usually at the function/method level or sometimes at the module level especially for the testing of exceptional situations, as most exceptions are not caught in the function that generated them. Tests are often written before the code to be tested. This leads to what is known as test driven development. There are many frameworks that can help with testing. CppUnit is a port of JUnit. There's Google Test but I haven't had the opportunity to use that yet. There's also Boost Test, part of the Boost libraries which you can use with Turtle for mocking. You can find Turtle on Sourceforge.
The idea of having these tests within your code is that you can make changes, run the tests and ensure that the changes you made haven't broken anything and the code still performs to specification laid out by the tests. This is more regression testing though than unit testing, but the unit tests provide the backbone for regression testing.
Unit tests, as opposed to system tests, are meant to verify that the components of a project work individually. This allows you to make changes to parts of the system and verify that those changes do not break the existing function of the part that you're changing. They are also often easier to run than system tests, because they do not require infrastructure, such as a working http server, to run. Finally, working at a component level can be helpful to cover edge cases for a component that you would not have though of looking at the whole system.
What qualifies as a component may vary depending on your system, but smaller components are better for testing. You may aspire to have unit test for every class. Also it's important that you have unit tests for everything; every piece of code is part of some component.
As with all testing, the goal is to prove that your application works. Specifically unit tests prove that all the pieces work, therefore the whole thing together probably works. Ideally, you want it so that it's impossible to make a functional change to your program without breaking a unit test. Likewise, another metric for good unit tests is code coverage: your unit test should ensure that every possible code path is tested and verified, within reason.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
