A Primer on Unit Testing

Seneca offers a course on introductory Java Programming for fourth semester students of its CPA, CPD, and BSD programmes. I'm enrolled in it right now, and I must say, I feel like the course's name sells it short to some extent. Students learn many things beyond the scope of the Java API. For instance, in our first assignment, we were asked to work in groups to craft and perform unit tests on the classes we designed using the JUnit framework. Automated testing is a fairly new concept to me, but I found it to be useful and interesting. It would seem that the idea is to speed up the development process by testing code quickly and efficiently rather than writing and rewriting test mains that may overlook certain aspects of code and are really tailored to one type of logic or a particular naming convention. As with any other team-based exercise, it has its ups and downs, and I wanted to share some things I feel are good practices in test-driven development.

Ensure that all business requirements are understood before you start designing and writing code

This is something that seems like common sense for most developers, but we're also human, and we have a penchant for missing things that ought to be obvious (missing semicolons, anyone?). The great thing about working in a group is that you can sort out ambiguities and point out things that you might have missed. You can talk over what the client seems to want, debate as to whether a particular design meets those requirements, and optimize the design to suit your needs.

 For each business requirement, device a use case and desired output

A big part of testing is understanding exactly what the end user experience is going to be like. What will the user do? And what do they expect to see as a result? Think about all that is expected by a client from your solution, and what those expectations entail for the end user. This will inform your design and your tests.

Test each business requirement individually, then use a suite to barrage the completed design

It will save you time and effort to test a business requirement in a vacuum to determine if it meets business requirements than to wait until the very end to test everything and having to dive into layer upon layer of code that is likely to feature layered inheritance and multiple imported packages. This is an arduous process and one I had to endure in delivering this assignment.

Choose sensical testing values, especially when testing numerical inputs

It's important that you account for all kinds of user input, yes, but you should ensure that you can parse the input easily and visualise the output. Choosing a string of random numbers will not help a developer test their output in a timely fashion.

 Document your tests appropriately

Commenting and documenting your tests are an essential part of the process. Commenting assembly line code isn't really a necessity - if your code is well-written, it should speak for itself - but testing code is a different story. A developer should be able to trace their exceptions and logical issues easily, and commenting code can give them a great deal of insight into where to look.


I'm sure there's a lot more that can be said about this process - entire sections of bookstores are devoted to it - but this is what I've thought of with my little exposure to this concept. I hope it's of use to anyone who might read this. And if you're more knowledgeable about the topic, please do share your thoughts on it with me!