Scala Specs gets my vote! :-)
Specs is a behavior-driven-development testing framework written in Scala. It can be used to write tests for Java and Scala. It was inspired by RSpec - a testing framework very popular in the Ruby world.
An example test written in Specs:
import org.specs._
object ElementSpecification extends Specification {
"A UniformElement" should {
"have a width equal to the passed value" in {
val ele = elem('x', 2, 3)
ele.width must be_==(2)
}
"have a height equal to the passed value" in {
val ele = elem('x', 2, 3)
ele.height must be_==(3)
}
"throw an IAE if passed a negative width" in {
elem('x', 2, 3) must throwA(new IllegalArgumentException)
}
}
}
Impressive, isn't it? :-)
Some will say otherwise but I would suggest that you separate TDD and Unit Testing. TDD is quite a mental shift and unit testing appears initially to take time. If you consider them to be one item, there's a risk that you won't see enough benefit immediately and there will be a temptation to simply drop TDD and Unit Testing with it.
First thing is to write some Unit Tests. They don't have to be perfect at first. Just teach yourself how to test small units of code and how to use mocking to isolate components.
This is the biggest time-taker but has by far the biggest payoff. Once you notice that you no longer have to page through 14 web pages to get to the one you want to test, you'll know what I'm talking about.
For me, the big Eureka moment was a Windows app where I was trying to test a regex which required I fill in two forms before I could get to it. I installed NUnit and wrote a test around that method and saw how quickly I saved hours of testing time. Then I added more tests to deal with the edge cases. And so on.
Then learn to write unit tests well. Learn the balance between brittle tests which are quick to write and writing many many individual tests. This is fairly easy. The lesson is that ideally each test only tests one thing, but you quickly learn how long that takes, so you start bending a bit on the rule until you write a test which breaks on every code change, then you move back towards the right balance (which is closer to the former than the latter).
TDD is, as I said, a major mental shift in the way you work. However, it won't add much time to your development process once you're already writing tests anyway. And you will, I promise, see your coding style improve before your very eyes. Or rather, if you don't then drop it, it's not for you.
One last thing to bear in mind is that TDD is not limited to unit tests. Acceptance test driven design is every bit a part of TDD. Another good reason not to mix them up in your mind.
Best Answer
Generally you will not need to duplicate every unit test. You should identify what is really dependent on the locale (good checklist is here). Many things related to internationalization are subject to the higher level of testing then unit-test.
If you are dealing with the string data that may come in different encodings, then you can utilize "data driven testing", i.e. passing data in different encodings to the same test method. For Java the TestNG is best suitable for this.
Another possible problem is the date/time formatting and parsing. Most locales uses : to separate time elements, but there are ones who uses dots and Brazilians uses h m and s (12h15m30s). This also can be used by passed data in different locales - you do not need to test all of them.
And testing GUI with right-to-left locales is usually not a subject of unit testing.
The bottom line is that you need to identify what data in your unit tests is locale-specific and use data-driven testing (data providers) to supply this data to your tests.