Sh*t my brain says and forgets about

Tag: JUnit

An idea for a college course :: Unit Testing

After spending a significant amount of time this week on writing JUnit tests for a Spring Web app, I’ve come to a conclusion.  College courses, even in the grad classes I am taking don’t spend enough time on the concepts behind unit tests.  Granted JUnit and NUnit has been covered in the classes I’ve had but really only the testing framework is discussed.

Test-driven development (TDD) teaches us how to write a test first, make it fail, stub out your methods, and then code until your test passes.  The practicality of TDD in the real world is limited because a requirement is to have your system well designed up front.  Getting to a point where you’ll know method names ahead of time means you’ve spent a significant amount of time thinking about the design and analyzing that design. 

We all know that is rarely the case.

There needs to be a course on the concepts that we need to keep in mind when designing a system so it can be tested later.  What kind of concepts?  Understanding exactly what you shouldn’t do to make tests difficult – limited coupling and high cohesion.  I started to get a better idea of those concerns when I took a training course on the Spring Framework.  Spring lets you use plain old Java beans for most of your core controllers which lets you test the functionality of the controller and not have to test the framework.  Keeping those concepts in mind during your development will help out later.

In this last semester I took a software engineering course.  In one of the lessons, a simple rule came up that I felt was totally appropriate for this theoretical Unit Testing course.  Any methods you create should only take the exact type of arguments you’ll use in that method.  If the method calculates a pay increase for an employee, the method should take float for the current pay and a float for the percentage increase.  Creating a method signature with an Employee object and something like an AnnualReview object doesn’t define the method, it only confuses the developer.  How can you write a JUnit when you don’t know what the method is going to use?

So that’s enough of my rant for now.  I think I’ve written more in this post than I did for my final paper in the class.  Ha!

JUnit Testing

I’d like to point out that writing JUnit tests after the fact is a pain in the ass.  I like to think I know enough about software engineering to develop software that has high cohesion and limited coupling.  Not following test-driven development allows me to forget some of those simple rules and now writing EasyMocks is killing me.

Powered by WordPress & Theme by Anders Norén