Working with DartEditor build 2559 and svn revision 2559, unit testing is available. The framework is not extensive at the moment but enough to get your TDD on. Most of the unit tests depend on the Expect object. At the moment you need to have the dart unit testing sources, they are located in the bleeding_edge tree. In this document we will create a simple dart unit test exampled named dart-unittest-example
A common application structure has still yet to fully emerge for dart, but something as follows should work for now.
sample - contains sample applications against the src file.
src - contains the core code of the library or application.
test - contains the unit tests against the src code.
third_party - contains code that is referenced from the outside.
Creating a test application in DartEditor called vector2Test in the test folder. This will be used for testing our src code.
Create a third_party folder to host the unit test code from dart. Export the dart unit test framework from bleeding_edge via SVN. The code checked out will give us the ability to create unit tests for our src code.
In the DartEditor open the vector2Test and add references to the unit test code by importing them as libraries.
DartEditor may have a bug dealing with #import at times, if darttest and unittest do now show up you have a few options. Restart DartEditor and hope for the best, change the location to absolute path and restart DartEditor, or wipeout the workspace directory and open the project again in DartEditor. Hopefully you need none of these solutions.
What the unit test package structure should look like after imported.
In the main entry of the unit test project create and call run() on DARTest object. This will generate a nice unit test UI in webpage to run the unit test results.
The common layout at the moment is as follows and referenced as group()/test()/expect(). Create a function that has a group of tests. In a single group include tests for testing a specific part of code. The group(name,f()) method takes a name and f() as its parameters, so each f() is expected to have a list of tests. Test is formatted the same way test(name,f()) where f() in this case is where you would test some data with Expect. A routine could be defined higher level in the function to setup any data you want fresh in each test. That routine will need to be called on entering of each test() method, setUpData() gives an example of such routine.
Creating some simple tests borrowed from total_dartest.dart in the bleeding_edge tree. This should be done just to prove to your self that the unit test framework is working. Add this code to the vector2Test.dart. Call the fakeTests() from the main() entry so they get picked up by the unit test runner.
Now running the application from DartEditor should come up with a DARTest: In-App View. From here you can run the unit tests by clicking on the play button.
Exploring dartest.dart we can see that it references the unittest.dart. DARTest is the visual view and the shared.dart provides us with the methods for testing our data. To keep things simple we only use the Expect. Beware, for whatever reason on build 2559 Mac OSX, trying to open expect.dart cashes the editor to crash.. So save your work often.
By this point we can start to define what we think our object should do. I personally like to start defining an interface and a constructor object. This might not be the correct pattern of play for dart, but its something to go with. Create dart library that include the following files
src/vector.dart - The actual library that would hold a vector library.
src/vector2.dart - The interface of the vector2 object.
src/vector2Implementation.dart - The implementation of a vector2 object.
Create enough implementation that the DartEditor can load it up.
At this point the DartEditor should have enough to open vector.dart and provide a nice looking package.
Lets create some tests cases against the vector2 object by adding a vector2Tests.dart. This class will host all the test cases for vector2 object. We could of put the test cases into the vector2Test.dart, but this would then mean it was coupled with the view of the tests. So to try and decouple we #source it in to vector2Test.
Testing the constructor by first importing the vector library into vector2Test.
We start with a simple constructor test.
Run the vector2Test project from DartEditor.
Add some additional unit tests and run.
Create samples for others to “touch&feel” our library or application first hand after testing. This could be part of a dart project life cycle. Create a sample project vector2Sample in folder sample and import the reference to vector project.
Hopefully this give enough information to get started with the unit test framework and provide feedback to the dart team on how you used it. The source code for this could be found here.