How to use unit testing?
There are a lot of frameworks for different languages, which provide functionality of unit testing. There is a lot of information on how to use each of them technically. Just like “import to your project this lib, type assert, compile, run and blah-blah-blah”. And it all is easy to learn.
The place I’m confused in is how to get it: which test to write, to cover large amount of possible bugs?
For example, assume we use jasmine framework for JS, and we are to test email validation function.
Great. Our simple code will look like this:
describe("Email validation test", function() {
it("isEmailValid("[email protected]") should be true", function() {
expect(isEmailValid("[email protected]")).toBe(true);
});
});
But actually we have no ideas how does isEmailValid function is written and where can it fail. Maybe it works only if we have gmail.com domain? So we should include another one test with any other domain.
Or maybe it doesn’t work if we have some very specific domain, just like “warhammerhobbitbanachspace.am”? In that case it would be rather difficult to catch a bug. Or, even, impossible.
Or maybe it’ll fail if we have more than 42 symbols in the string with email? Or maybe it’ll fail if we have exactly 9 symbols?
And that is only a little amount of examples of places which it would be useful to test. And that is just a simple string validation function…
And how can we really test some complex objects then? Yeah, I know, it is impossible to test everything. But how then to choose what really should be tested, and what not?
Are there any books or articles, which explain … some patterns/techniques/principals of covering the code with useful tests?
0
I find unit testing useful in two distinct stages and in two distinct usage patterns.
-
When you are building new code, it is difficult to even see if anything is working because the code that exercises or depends on your code, is not done. So, you write unit tests, that test your code in a black box fashion. The test assumes that someone somewhere will call your function with appropriate parameters ( right now, provided by the unit test system ) and your function will respond with an appropriate, non exceptional, non crashing, correct response. So this way you can develop code in parallel with other system activities ( sometimes even in parallel with design and architecture, but, alas )
-
Once you have the system working and producing some kind of value for users or being shown as a prototype, then, you have to change some underlying infrastructure, like the database connection. In this case, regression tests are invaluable. The working code you have actually has probably hundreds of hours of testing because as you develop, you test. Once you change the underlying assumptions in your infrastructure, you lose all those hours of reliability testing. It is really useful to have an automated regression testing system to rerun all those little unit test, over and over , while you tweak some parameters, such as the new database timeout or debug fundamental errors in low level code.
In the general case, it is impossible to prove correctness by testing.
Testing shows the presence, not the absence of bug
–Dijkstra
That being said, you can test your method with likely inputs and at least know that it works and have something with which to check for regressions (see Andyz answer). If you later discover a bug in your code, add another test case for that bug so you know you will at least not encounter that problem again.
1
What you seem to be looking for is the concept of test coverage, or more specifically for unit testing, code coverage.
There are many ways you can measure how well your tests cover the code, from the very high level e.g. you could say your isEmailValid function produces two possible outputs :. all inputs can be partitioned into two equivalence classes and you can get full coverage of those classes by testing a single member of each.
But at unit test you more likely want to look at a more low level measure such as statement coverage, which would allow you to see that you have tested every statement within the function, not just each observable output
3
I simply write the test, than have a look at what is covered and if not all is covered, I write another test to cover parts missed by the previous tests.
I use TestNG because it has some nice feature JUnit hasn’t (e.g. groups) and than check the coverage with EclEmma. Both plugins work smooth together in
eclipse.