Unit Testing Best Practices

With the agile shift in software development, unit testing has become more and more important.
I like to say that a good programmer is one who knows how to write good unit tests.
A good unit test grants that tested code is correct, testable, readable, reasonable and even elegant!

So how to write good unit tests?

This is my personal best practices list:

• always use tdd: it grants that the interfaces of your classes (i.e. your api) are created in a real life scenario; testability improves code readability and inner structure, giving it a simple design
  
• use data builders: tests require to create many objects; use data builders to build them; style your test building code defining your own dsl for data building
  
• don't use db-unit, use db builders: db-unit context files are external to the tests, making them less readable and self-contained; these files duplicate code and are hard refactor and maintain (does eclipse refactor automatically an xml/excel ?); so apply the builder pattern to create db objects in java too
  
• use light-weight mock: don't try to verify the internal behaviour of a mock, just mock its external behaviour; digging into the internals of a mock exposes to much information making the test fragile; most of the time you can check the correctness of the class under test just by checking it externally (by the way my favourite mocking library is mockito)
• write readable asserts: use a matcher library such as hamcrest or a dsl like fest-test
  
• use dsl when possible: there are nice libraries out there (time4tea, fest-reflect) that can make your test (or actual) code more fluent, and you can easily create your own (i did a small one for date manipulation, maybe i will post it later on)

That's it.

So go unit testing right now :)

Who is gonna be the next Java?

After java went out in 1995, it was difficult to think it would have reached such a widespread adoption.

There were several others OO programming languages around (C++ went out in 1983), but key to the success of java were a few language enhancements, the focus on enterprise (i.e. web) development and a strong marketing and commercial strategy.

Now many claims Java is old and stale.
So who's gonna take its place ?

Omitting commercial reasoning, we have a plethora of potential alternatives: ruby, jruby, groovy, scala....

We can see that none of them impose a big shift in programming paradigm: they basically combine object orientation with funcional pardigm.

But scala is the only one to be at the same time:

• statically typed: checks type at compiler time, but avoids redundant typing through a local type inference mechanism
  
• fully java compatible: it can smoothly run on a jvm, leveraging existing libraries and code base
• java targeted: Martin Odersky created scala with the intent of making a better java, so it looks more natural to java programmer than other languages
  

So at the time my bet would be on scala...