When I started experimenting with Dart some time ago, I looked around for some pointers on unit testing with Dart and found a post on a blog titled “Test Driven Dart Development” and a Google Docs page. Both describe a unit testing framework that is not part of Dart’s standard library but can be downloaded from the Subversion repository of Dart.
I downloaded it and started writing my first tests. I didn’t like that it used a style that I perceived as being inspired by JUnit 3, though. It also has a nice grouping feature, but groups looked a bit to unspecific to me.
At it-agile, the company I work for, everyone gets 30 slack days per year we can use however we want — as long as it has some connection to agile software development. So I decided to invest some slack days and try to implement my own testing framework. I wanted it to use matchers like the ones provided by Hamcrest. I liked that grouping feature of the existing testing framework but wanted to give it more meaning. As I pondered this I remembered that my colleague Sebastian Sanitz once introduced me to a JavaScript testing framework named Jasmine and upon revisiting it, I decided to build something similar for Dart.
As it is inspired by Jasmine and is implemented in and for the Dart programming language, I named it “dahlia”. Like “jasmine”, “dahlia” is the name of a kind of plant and its name start with the same two characters as “dart”.
A dahlia test looks like this
describe('two equal strings', () {
it('should be equal', () => expect('test').to(equal('test')));
});
Like in other BDD testing frameworks (the most widely known being RSpec), the describe-part describes something that will be tested and the it-part specifies and tests the behavior of the tested object. So you read this text “two equal strings should be equal”.
The parameter to expect() is the actual value, the one you want to test. Typically you call a method on the tested object here and test whether it mets your expectation. The testing part is the parameter of the to method. It is a matcher. Here an equal matcher is used that simply tests whether the actual value equals the expected value which is passed as a parameter to the matcher. Currently there are only a few basic matchers but the number of available matchers will be expanded in the near future. It’s fairly easy to implement your own matchers should the need arise. You just need to implement the Matcher inferface and provide a convenient function like the equal-function in this example to provide a new matcher.
The expect-part is – similar to the describe- and it-parts — meant to be easily readable. In the example this leads to “expect ‘test’ to equal ‘test’”. The it-function takes a function as its second parameter. In many cases those will be simple one line functions like the one in the example, but if some setup code is necessary, a full multi-statement function can be passed here. The it-call is also called a specification as it defines a behavior and a test for it. Every it-call is therefore counted as a “spec”. The total number of specs, of failures — failed expectations – and crashes — any other exceptions that may occur — is displayed at the end of a testrun.
Currently there is only one reporter that prints the test run results to the console — be it the Dart VM console in DartEditor or Dartium or the script console in any browser –, but other reporters that create HTML and other formats will be added later. As dahlia is currently ment to be used for unit testing, the output to the console is the kind of output one needs the most.
dahlia is available at GitHub. If you are interested in Dart or are already developing with Dart, please take a look at it.