JUnit best practices in Java
No doubt writing good JUnit test cases is a rare skill just like writing good Code. A good, well thought and well-written JUnit test can prevent several production issues during initial development or later maintenance in Java applications. Though one can only be perfect in writing the JUnit test by practice and a level of business knowledge which is important to envision different scenarios on which a method gets called, some best practices or experience of another developer may help to guide other programs. In this Java article, I am sharing some JUnit tips and JUnit best practices that I have learned and follow while writing unit tests using JUnit for Java programs.
One of the books which helped me a lot is Pragmatic Unit Testing in Java with JUnit by Andrew Hunt and Dave Thomas, This book shares a lot of JUnit best practices that are worth reading and learning if you are serious about Unit testing using JUnit.
Never undermine the importance of automated testing and test cases written by the Developer who writes the code and that's the reason many companies are asking programmers to design, code and provide unit tests during their Java interviews.
One of the books which helped me a lot is Pragmatic Unit Testing in Java with JUnit by Andrew Hunt and Dave Thomas, This book shares a lot of JUnit best practices that are worth reading and learning if you are serious about Unit testing using JUnit.
Never undermine the importance of automated testing and test cases written by the Developer who writes the code and that's the reason many companies are asking programmers to design, code and provide unit tests during their Java interviews.
These JUnit best practices not just apply to JUnit but to any other testing framework as well like TestNG, they are more on testing and writing test cases which are more important skills than tools like JUnit or TestNG.
10 Essential JUnit Best practices for Java Developers
Here is a list of 10 JUnit best practices I have compiled, As I said these best practices are related to testing, thinking test cases, and writing test cases rather than focusing on JUnit features like Testing Exception or Timeout.
1. Always test Core Methods
It's not practically possible to get 100% code coverage, so don't aim to write unit tests for each method and trivial operations, instead, write unit tests for a method that is likely to have bugs during maintenance. Always test core method and core classes which are used heavily by different parts of a program.If you follow this best practice while writing a test, you will be surprised with the quality of code, it often results in fewer bugs during the formal testing cycle.
2. Run the JUnit test as part of the Build Process
You should Integrate Junit tests with your build script so that with every compile your tests run automatically. Maven and ANT two most popular build technology for Java applications provides support to run Junit tests. This is not just a best practice but a standard of building Java applications.Always run test cases while building projects this not only verifies new code but also alerts with any potential error which results due to recent changes. Sometimes while fixing a bug developers introduce another bug if you have a JUnit test integrated with the build or following CI practices then you are better prepared to deal with them.
3. Always Test for boundary Conditions
Develop test cases based on usage and boundary conditions, This is my favorite Junit test practice and mostly asked as an interview question on JUnit as well. For example, if you are asked to write a function to replace all occurrence of a given character from String e.g.
public String replace(String text, char ch){ …}
How will you write a test case for that? to my surprise, many Java program starts focusing on JUnit test syntax like setUp() and tearDown() even before thinking of actual test scenarios like :
1) Test for empty text or empty character?
2) Test for the character which is not in String?
3) Test for characters that come during start, end, or middle of String?
4) Test to cover if text String contains just one character which is equal or not equal to the replaced one?
5) Test with String contains just contains one character multiple times?
These are just a few test cases I can think of but the idea is to focus on what to test and not how to test, most IDE like Eclipse and Netbeans will take care of that. Though you should have basic Ideas of the essential functionality of JUnit testing like how to test Exceptions, Timeout, etc.
4. Alight Test with Business Requirements
Make sure your JUnit test is aligned with your business requirement specified in the BRD or Business Requirement document.5. Tests for Non-Functional Requirements
Write a test for the non-functional requirement as well, while writing a Thread-safe class, it's important to write tests that try to break thread safety.6. Test for Ordering
If a function or method depends on upon the order of events then make sure your JUnit test covers ordering requirement and my take is to test both sides of the coin means with correct ordering method should produce a correct result and with incorrect ordering, it should throw Exception or confirms the alternative operation. Another JUnit best practice that is worth remembering.7. Use @Ignore Annotation
One Idea which helps me while writing a unit test is to create dummy tests while working with requirements because that’s the best time you remember requirements and having a test case with a comment that describes the intent of test lets you to implement it later or just put @Ignore if you don’t have time to implement test and using Junit4 annotations. This helps me to cover most of the requirements while writing code as well as test. this just enforces you to write as many test cases as defined by requirements.8. Avoid testing simple getter methods
Writing trivial JUnit tests like for getter and setter method is mostly a waste of time. remember that you don't have the liberty to write an infinite number of unit tests either in terms of your development time or while you are building your application. as unit tests run automatically during the build process, they are required to finish early and trivial unit test just adds on time and hide more useful case to run later.
9. Avoid dependence on Database and File System
Keep your Unit test independent of Environmental data like Database, File System, etc. The unit test depends on environmental data that may work in some environments and may not work on others. It's a good idea to use a carefully chosen set of data embedded in test cases as well as a placeholder method that can be plugged to the database if required using configuration.10. Use Tools
You should always use available tools like DBunit, XMLUnit, and Spring test framework based upon your project and your need.
In Summary code, review and Unit testing are as vital as writing good code and good comments. Think through requirements while writing test cases and focus on scenarios. I hope these JUnit and testing best practices will help you to write better code. I highly recommend you to follow the Test Driven Development because it results in better code and design.
Most of these JUnit Best practices can be asked as JUnit Interview question. They are very fundamental and anyone who claims to work on JUnit 3.8 and 4.0 should know answers of these question. Please share some more JUnit interview questions
ReplyDeleteOne practice we use while writing JUnit test is to create an Abstract base class for all test. Responsibility of that class is to configure system for testing e.g. providing configuration data, setting up database and clearing it after end of test case. Its more like a system wide setUp() and tearDown() method.
ReplyDeleteSecond best practice is to create meaningful assert method for your own use, for example you can create assertCustomer() method which further assertCustomerID(), assertCustomerName() or any other parameter, which needs to be asserted but not available via equals() method.
One thing I learn while following Test Driven development is that you can use default implementation to provide dependency in order to execute your JUnit test. For example, if your code needs a Sender which sends message over Socket, instead of using actual Sender object, you can create an implementation of Sender interface which just print "Sending message" instead of actually sending message. This would be enough to test that module, which has dependency on Sender.
ReplyDeleteIf you are writing JUnit test for data access code, one of the best practices is to make sure you delete the data after test e.g.
ReplyDeleteinsert data
validate
delete data
By the way make sure, your data should deleted even after validation fails.
One of the JUnit best practice is to design for test-ability. Your code should be written on interface than actual implementation. For example, if you have a method that is meant to output to a file, don't pass in a file-name, or even a FileWriter. Instead, pass in a Writer. That way you can pass in a StringWriter to capture the output for testing purposes. Then you can add a method (e.g. writeToFileNamed(String filename)) to encapsulate the FileWriter creation.
ReplyDelete