Schlagwort-Archive: TDD

TDD Test aufräumen

Es ist generell wichtig nach einem unit Test den Code aufzuräumen, also angelegte Daten wieder zu löschen. z. B. Testdaten in einer Datenbank.

Aber noch wichtiger ist es vor einem unit test aufzuräumen.

Damit wenn bspw. während eines vorherigen Testlauf etwas schief ging und der Test nicht bis zu Ende durch gelaufen ist und somit noch Testdaten in der DB liegen, der nächste Test ordentlich und sauber durchgeführt werden kann.

Merkhilfe für gutes Design

1) Switch-Konstrukte oder nicht-elementare if-Statements (alles, was nicht mit <,>=,==,|| etc geprüft wird)
weisen auf einen Design-Fehler hin, den man durch Polymorphismus lösen kann. Bsp: Methode male() vor und nach Benutzung von abstrakten Methoden
2) Vererbte Dinge sind immer in den Unterklassen da, aber nur public v/m sind echt “sichtbar”
3) Man verwendet immer private für Attribute einer Klasse und macht sich Getter/Setter um in Unterklassen (und evtl auch aus anderen Klassen) darauf zugreifen zu können
4) Vererben tut man, wenn verschiedene Objekte in Teilen gleich sind und sich gleich Verhalten
5) Abstrakte Klassen nutzt man, wenn es die Oberklasse an sich gar nicht gibt
6) Abstrakte Methoden nutzt man dann, wenn man vererben möchte, die Funktionalitäten aber in jeder Unterklasse anders implementiert werden müssen, und nicht gleich sind.
7) die Implementierung eines Interfaces ist sowas wie das Implementieren von abstrakten Methoden einer Superklasse, nur besser!

Gefunden hier:

Compile, Run And Develop Java in the Console, Setup for TDD with JUnit

When you want to learn Java it is good to know about the basics.


  1. Text editor
  2. Java installed

check if java is installed.

java -version

Should be displayed something like that:

java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07-348-9M3406a)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-348, mixed mode)

Creating Development Structure

expected we want to create a project folder and in it an src,bin,lib,test folder.
src = here you create source files (packages)
bin = Output folder
lib = for Libraries e.g. JUnit.jar
test = mirroed the package structure from src, here you develop your tests.

mkdir project
cd project
mkdir src
mkdir bin
mkdir lib
mkdir test

Write a first very simple program

cd src

type the following:

public class Main{
 public static void main(String[] args){
  System.out.println("Hello User");

Back to console compile! Just to see it runs. (You are still in folder src)


You should see now 2 Files and Main.class
To run the program just type

java Main

You should see

Hello User

Now delete the Main.class file.

Use Packages

It is recommend to use packages.
create a package (mkdir mypackage)
Java conventions says package names is always lowercase and have no special characters.
move into the package

mv mypackage/

Now compile (you are still in src)

javac mypackage/

You can run the program with 2 Ways

cd mypackage
java Main

Or back in folder src we have to set the classpath (-cp)

java -cp mypackage Main

Set output folder

delete mypackage/Main.class

javac -d ../bin mypackage/

Now the Main.class file should be in bin folder.
Run the program

cd ../bin
java Main

Or go to project folder and call the Main with classpath

cd ..
java -cp bin Main


Programmers are lazy so set the classpath.
To view the classpath type


If the output is Nothing then the variable isn’t set.
ensure that you are in project folder

export CLASSPATH=./bin

Now you can start the program from here with

java Main

Install JUnit

Download newest version from
Copy the download junit.jar file to your lib folder.
Add the jar to CLASSPATH

export CLASSPATH=$CLASSPATH:./lib/junit-4.9b2.jar

Test wether you reach the JUnitCore class

java org.junit.runner.JUnitCore

You should see something like this.

JUnit version 4.9b2
Time: 0,001
OK (0 tests)

For more information take a look at

Write a Simple Test

Go to test folder and create a Class SimpleTest with the following content

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;
public class SimpleTest{
    public void testEmptyCollection(){
        Collection collection = new ArrayList();

Go back to project folder, compile and run the test.

cd ..
javac -d bin test/
java org.junit.runner.JUnitCore SimpleTest

Should be output

JUnit version 4.9b2
Time: 0,006
OK (1 test)


The example is taken from

The Cost of Testing or You don’t Know what You are Missing

The Cost of Testing or You don’t Know what You are Missing

Twice this week people challenged my belief in automated testing and Test Driven Development. The argument that was brought forward was simply: Unit tests are too expensive.

I actually believe the opposite is true. Let me tell you about a little dialog that happened in my development team after two developer where working on a feature for about an hour or two.

First Developer: “I think we got everything. Lets start the application and see if it works.” (starts the application)

Second Developer: “Hmm, doesn’t work.”

First: “Oh, I know, we forget to actually invoke the new feature” (fixes that and restarts the application)

Second: “Looks great. It works. Lets commit it to SVN”

What’s so special about this? They didn’t start the application a single time during the development process for over an hour. Can you do that without writing tests? Of course you can and you will spend restarting the application during the rest of the day until you fixed all the bugs. How long does your application need to restart? Including the time you need to navigate to the state where you can test your application. How long does that take?

Not having to do that. Or at least not very often is a huge time saver. And it’s not only the direct cost of restarting the application. Waiting for the application is often an interruption of your concentration. Do you really think about the next aspect of the feature to implement? Or do you check mail? Get a coffee? In my experience going Test Driven in Pairs is a way more concentrated type of working.

And that is not even considering that your tests will run over and over again, making sure later changes don’t break anything. This alone saved my butt a couple of times.

If you reached that level of TDD it will save money for you and your team. I promise.

But I’ll admit, I didn’t believed that a couple of years ago. I was using tests only when implementing rather abstract stuff. And I thought it wouldn’t be possible to efficiently automate tests for most of the code we wrote. I had to learn a lot. Testing isn’t easy. Most of the code we produce isn’t fizz buzz, but is concerned with GUIs and databases, both make testing hard and expensive. But these problems can be solved, so you can gain the benefit of TDD even for these cases.

And as a side effect you will have to come up with a really nice and clean design of your code in order to test it. This in itself will make future changes more easy and cheap.

Therefore I urge you: Start learning how to test today. If you don’t you will never know what you are missing.

And if promises don’t motivate you: I’m convinced that in a couple of years from now the places where you can just puke code into your IDE will get rare. So if you still have a couple of years to cover until retirement: Beef up your testing skills. It’s one of the best investments you can make in your own future as a software developer.

via Schauderhaft » The Cost of Testing or You don’t Know what You are Missing.