[stackoverflow]

I am staring up an OOP design and software engineering class tomorrow and they have us doing unit tests, test driven development etc. I dove into the class notes already.

My question is, when and how do you write these? This is what I have gathered:

* Before writing any code for the project, you design your program etc.

* Write all tests before starting to code

* Tests should include boundary tests and exceptional cases etc.

* Code the project to meet the requirements of the tests and nothing more

Now this begs the question, how many tests should you be writing? Should we be writing tests for all public methods only?

In other words we can wrap this up...

Do your designs/uml etc. Then write a bunch of unit tests. Finally you code to pass your tests. Go back and optimize/refactor and run more tests etc.

[macosxnerd101]

At that point, you're probably over-designing or the project is pretty big and there are enough people to devote to it. I look at testing this way: start with what the component is supposed to do (what values it accepts, what it should return, extraneous and erroneous cases, etc.). Next, write the component to see what you end up with. You may find yourself tweaking the design. Finally, write the unit test for the component. No use writing a unit test if you change things up. In bigger projects, the senior developer(s) may have the method headers, etc., pre-defined. Things are still subject to change, though.

[stackoverflow]

That sounds quite a bit more relaxed than how the class lays it out.

I have always done, "testing" while I code. I usually set up a dummy program to test classes, functions etc. So I am still trying to comprehend why "unit testing" is any different than what I have always done. So far it seems like glorified debugging.

[macosxnerd101]

Unit testing is used to demonstrate a component's functionality and ensure it works. So in production, when something fails, you can look back at the tests. They are also designed to help prevent these kinds of failures and make component integration a little easier. Plus, the examples in the unit tests are a form of documentation for how everything fits together.

I'm not surprised at your class. Academia != real world. But it's better to be hard-nosed about it and get people doing things more rigidly, than having a relaxed standard for the people who are lazy or just don't know any better to blow off or do the work incorrectly.

Also, I figure I'd add that I come from an Agile background.

[blackcompe]

Use JUnit. If your using Netbeans or Eclipse there are plug-ins that will generate the boilerplate for you.

Usually the QA team member writes test cases in parallel with component design just after Object-Oriented analysis and design has completed. Just write as many appropriate test cases you think are needed. Usually it's just simple things, like making sure your code doesn't break for parameter values it doesn't expect (nulls, negative values). Try to invoke unhandled exceptions. Your aim is to try and break the code and have it fail in an unexpected way.

Your not testing functionality (e.g. does the system produce the report that was detailed in the requirements specification document). That is left for the client and QA team at a later time.

As for documentation, specify your test cases in a spreed sheet. E.g.

Date		Component Name		Test Description					status
______________________________________________________________________________________________

8/22/11		Account.withdrawal	throws error for negative amount			passed
8/22/11		Customer.setName	name unchanged when passed a null value			failed

This post has been edited by blackcompe: 22 August 2011 - 06:29 AM

[stackoverflow]

Thanks, I will be using JUnit with Eclipse. I haven't tested it out yet but I read some of the beginners guide.

[Programmist]

I didn't see this or I would have responded earlier.

Your tests are basically your specifications written in code form. An architect doesn't build a house and then write the blueprint and neither should a developer. Writing good tests first ensures at least two things:

1. Your code conforms to the spec
2. Your code will easily testable and therefore be correct

There are books written on what constitutes testable code, so I won't go into it in depth. But in general any testable unit should be testable by testing its public behaviors and mocking its collaborators. Unit tests should be easy to write and should generally have one logical assert. If you want to take it a step further look into BDD (behavior Driven Design). It is basically TDD, but with a focus on user stories and domain. You can do BDD with JUnit (following the following the "Arrange, Act, Assert" mantra) but there are tools out there specifically designed for it in several languages (EasyB, Spock, Jasmine, ...).