What Have You Learned?

You can’t have a sophisticated piece of software without testing code. Sometimes (read: quite often), you’ll write as much or even more code for testing than you will for implementing the actual functionality. You might even try test-driven development—writing tests before you write the actual source code that’s to be tested, and making the tests drive the design of your program. We all know: tests are crucial! That’s why you have to make sure that your test suite is well designed and up to the highest standard.

It’s important that your tests are concise and to the point. Whenever one of them fails, the code should give you a very clear indication of where to search for the error. Most of the comparisons in this chapter focus on that aspect. We have shown you a template for structuring your tests that consists of given-when-then and makes them more understandable. You know that tests should stand on their own, and you learned how you can further improve their understandability by describing them with annotations and choosing the right assertions. You’re aware of a few common mistakes people make with JUnit tests—for example, by mixing up expected and actual values or choosing an improper level of precision. Last but not least, you now have a few techniques at hand that will help you to test a lot of your code base while keeping down the amount of testing code. You can get this done by testing the most critical settings, the edge cases, or by parameterizing your tests.

This chapter gave you a first glimpse of what the JUnit framework is capable of. And that’s really a lot. In fact, it’s capable of much more than we can reasonably cover here—we don’t want to write a whole book about unit testing with JUnit. Our aim was just to give you a head start on JUnit with some best practices. Fortunately, that book was already written: Pragmatic Unit Testing in Java 8 with JUnit [LHT15].

Now that you’ve learned about designing testing code, you’re ready for the following chapter—it’s high time that we go back to the actual source code and have a closer look at its design. So next, we’ll show you a number of design principles that you can apply to make your programs more object-oriented and robust.

Footnotes

[36]

http://junit.org/

[37]

http://jgiven.org/

[38]

If you’re interested in a comprehensive explanation, we recommend you read What Every Computer Scientist Should Know About Floating-Point Arithmetic [Gol91].

[39]

Since Java 7, you can use any unicode char that passes Character.isJavaIdentifierPart(int). Still, our advice is to stick to digits and letters in method names.

[40]

https://github.com/pholser/junit-quickcheck

[41]

Actually, it’s Klingon for the word “Klingon.” You usually don’t have to support that language in your program, but what about languages like Chinese or Turkish? Would your program work with those, too?

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.191.237.201