Keeping your code safe with Unit testing
Unit tests let developers internally control the functionality and compatibility of their applications when they made changes to features, code or the environment.
Believe it or not, unit testing is actually a controversial topic among Java developers. Some think that writing unit tests is a waste of time, while others consider them an essential part of the software development process, and the way to ensure that your new app doesn’t, well, suck because it wasn’t checked properly. And yet some developers are bored by the topic of unit tests.
Think of This Analogy:
Each time you enter your car and start it up, you take a look at the instrument panel/dashboard, almost automatically. even older cars are equipped with warning lights, some less serious (like that you need to fill gas), some more serious (like the battery status) and some highly critical (like the engine-is-gonna-explode warning light).
So if you see something wrong, like the “check engine” light is flashing an angry red warning, it probably wouldn’t be wise to start driving away. in a similar manner unit tests act as warning signals that something does not work as expected. it wouldn’t be wise to deploy code into production when all your unit tests are failing.
But unit tests are just that, early warnings and internal checks that your code does what is expected.
If you really, really know what you are doing, then you might disregard some of them. But this is not the normal case. And like the car analogy, your car without any warning might suddenly stop working (for reasons not detected by the status lights), just like how code that passes all unit tests is not necessarily 100% correct.
Before we get into the blood and guts of the report, let’s review a very brief list of points to remember:
- Unit tests are code themselves (so they might also have bugs, ha!)
- Unit tests perform a small task and then verify that the result is the expected one
- Unit tests that are failing are a warning signal that something is wrong with the expectations of the system
- Unit tests that pass do not guarantee 100% correctness of the code.
- unit tests should be updated if the requirements change
JUnit and Testing for Advanced Guru-Types
JUnit is one of the most popular testing frameworks available, and TestNG brings some more advanced enterprise features to your ongoing efforts to keep your code clean, testable and verifiable at all stages of application development and deployment.
If you’ve heard anything about unit tests in Java before, then you’ll know that the de facto testing framework is JUnit, so most of our examples will use it and the major Java ides (i.e. eclipse, intelliJ idea, netBeans) have explicit support for it.
JUnit is a port to Java from the original SUnit from Smalltalk created by Kent Beck. Since then similar libraries exist for other language as well such as nunit, phpunit, Cunit. Here is a comprehensive list of other testing frameworks.
TestNG (test next generation) is another framework for Java, which can be seen as a more advanced JUnit. it is also possible to use other test frameworks for languages that run on the JvM to test Java code. Spock which is the test framework of Groovy can be used to Test Java and Groovy code.
Note: unfortunately, we have limited space in this report, so we’ll ask you to view certain parts of this content on the Zeroturnaround blog. The following parts appear in Why Your Next Cloud App will Probably Suck Without….Unit Testing:
- Get started by setting up a “hello world!” unit test, will all the code you need to make it happen
- Seeing your unit tests from the end-user perspective, driven by the features required.
- Unit testing as a warning signal for later (i.e. what happens we a new dev joins your team in 2 years and starts playing with legacy code?)
However, let’s continue with some more advanced stuff for those of you who already checked out the blog. Please note that, unfortunately, some code snippets are too long to fit in one column, and therefore carry over to the next. We are planning a fix for this in the future, apologize for this inconvenience.