Since I would consider myself a novice with Junit and java testing, I decided to take it upon myself to try a learn a bit more about it since we have been using it in class. I found a blog on ZeroTurnAround.com by David Salter that discusses a few tips on this topic, which I found to be quite insightful, so I am hoping to relay those tips to you.
The first tip is to follow the AAA pattern when writing tests. That is Arrange, Act, Assert. Arrange the conditions at the start of the method, act on the system, and then assert that the results are what you expected them to be. I am always a fan of easy ways to remember things, so I really like this acronym. It a nice easy way to remember what a good java code test should include.
To go along with the AAA, there is an important thing to remember when using the last of the A’s, assert. Although assert is a cool and powerful feature, you must be careful as to where and how often you use them. One should be careful that they are not testing things that the method wasn’t intended to test. It is also important to make sure you are not testing too many things in one method. This cause headaches if a tests fails, because it requires debugging multiple methods/classes, rather than being able to focus on just one. This tip really stood out to me because I think one can easily go down this rabbit hole thinking that they are making their lives easier, while in reality they are making it harder.
The last item I want to discuss is important to testing, but it is also important with regular development as well. Take advantage of what the software has to offer you. It can make your life a lot easier in the long run if you take the time to learn a new feature or two. Although you have to invest time upfront learning how it works, you can save a lot of time because that feature makes it easier for you to develop, debug, etc. For example, libraries like EasyMock and JMockit allow you use a mock object. This allows you to “mock” objects that do not exist yet. The example used in the blog us mocking a security system that controls who can access what, depending on the user logged in. Because you are able to create a mock one, you are still able to test your product, even though a key component is missing.
Obviously there a lot of different tips a whatnot to help make us better testers. This really is just the tip of the iceberg, but I hope it was as useful to you as it was to me.
Link:
https://zeroturnaround.com/rebellabs/top-testing-tips-for-discriminating-java-developers/
From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.
