A nice fresh web development take on Agile

It was a nice read with some great looking graphics and an interesting angle on the Scrum approach.
read here

Really funny map for old JVM fans

GOTO the big version of the map hier

Perl... Really!!!

How to stop your subordinates from becoming creative since everyone knows it’s the real threat …

Manual testing is immoral!It’s not just dumb, and it is dumb!IT IS IMMORAL!

Great Presentation by Uncle Bob (Robert Cecil Martin) where he talks about the original meaning of the scrum Master role, the importance of Testing and how 'scrum' and 'agile' took the wrong path. I could not find it in better quality…

Better quality Link of 'The Land that Scrum Forgot'

U need a programming language. Simple as that.

David Heinemeier Hansson talks about how ruby on rails lowers the bar and make programming more accessible. He stress the fact that 'There's No Such Thing as a "Pure" Programmer' but in the end accomplishing great thinks in programming can’t be easy, it takes thousands of decisions, so we will still need some language of expression, a programming language.

Full Interview on Talk on 'big Thing'

Positionierung von JUnit Tests innerhalb eines Projekts

Neulich ergab sich bei mir auf der Arbeit eine Diskussion über eine auf den ersten Blick relativ banale Angelegenheit. Die Unstimmigkeiten betrafen den Speicherort von JUnit Tests innerhalb eines Projekts. In diesem Fall war es ein Eclipse Java Projekt, doch sicherlich gelten die ähnliche Argumente für jede Projektstruktur mit einer Package basierten Sprache und einem Testframework.

Fragestellung

Folgende Frage stellt sich nun: Sollen die JUnit Tests in einem extra Source Ordner mit dem Namen "test", "JUnit" etc. abgelgegt werden oder sollen die Testklassen im gleichen Sourceordner liegen wie die zu testenden Klassen. Darüber das die Klassen und die Tests jeweils im gleichen Package liegen sollten waren wir uns aus verschiedensten Gründen einig. Die Fragestellung ist also welche Package Struktur die bessere Wahl ist:
1)

ODER
2)

Hier ist die Beschreibung der Problematik und eine Antwort die unter junit.sourceforge zu finden ist: link

Überlegungen

Für die Lösung 1) spricht, dass man auf einen Blick sieht welche Klassen einen Unittest haben und welche noch einen brauchen. Wird eine Klasse umbenannt oder verschoben ist es sehr schwer den dazugehörigen Unittest bei diesem Schritt zu übersehen. Die JUnit Tests sind darüber hinaus aus jeder Ansicht schnell zu öffnen und können per ANT relativ einfach aus dem build Prozess herausgenommen werden.

Für die Lösung 2) spricht die Tatsache, dass die große Anzahl an Tests den Inhalt der einzelnen Packages aufblähen und nicht zu Übersichtlichkeit der Projektansicht beitragen. Der Buildprozess wird vereinfacht. Mock Klassen, Infrastrukturklassen sowie Helper Klassen die nur für das Testen notwendig sind können hier gemeinsam mit den eigentlichen Testklassen relativ einfach untergebracht werden.

Im Netzt findet man unter dem Verweis auf "Best Practice of testing" in der Regel fast Ausschließlich die Anwendung der Lösung 2).
z.B. hier "It is considered a best practice in testing, to separate the test case code from the application code."

Nur selten trifft man auch auf die Argumente, die für die Lösung 1) sprechen.

Schlussfolgerungen

Will man in einem relativ kleinen Projekt das Testen enforcen so wird die Lösung 1) wohl die passendste sein.
In größeren Projekten wo mit Hilfe von Spring beim Testen ganze Architekturschichten ausgetauscht bzw. gemockt werden können und das Verständnis um die Notwendigkeit von Tests bereits vorhanden ist, wird die Lösung 2) wohl am effizientesten sein.