Thursday, October 31, 2013

Beautiful Acceptance Tests in Angular.dart

I ended yesterday with an Angular.dart acceptance test that looks like:
    test('Retrieves records from HTTP backend', (){
      inject((TestBed tb, HttpBackend http) {
        // 1. Stub HTTP responses
          respond(200, '[{"id":"42", "title":"Test Appt #1", "time":"00:00"}]');

        // 2. Apply all Angular directive to supplied HTML

        // 3. Wait a tick, then execute the first response {

          // 4. Wait a tick, then “digest” things

            // 5. Expect that the test appointment is in the DOM now
            var element = tb.rootElement.query('ul');
            expect(element.text, contains('Test Appt #1'));
That is not too bad, but I think there is room for improvement.

I start with #3 and “executing” the response. That struck me as odd, but while I was digging through the underbelly of Angular.dart's MockHttpBackend, it seemed necessary. I found that the callbacks that would trigger Future completion in my application code were stored in these responses and so I manually invoked them. Having some time to review, I now see that this is what flush() does.

In fact, I found it odd that I could not get flush() to work previously. I gave up on it when all that it gave me was “No pending request to flush !” errors. It turns out that the “Wait a tick” was the important piece necessary to allow the HTTP responses to be in a position to be flushed. So I change #4 above to: {
The other thing that I found off-putting last night was the call to $digest() on the root scope of the module. After digging through the Angular.dart library a bit today, I believe that is necessary. It manually forces bound variables (like the list of appointments) to trigger view updates. Angular.dart has a moderately complex algorithm to determine when to do this in a live application. Invoking $digest() in test speeds things along.

So flush() and $digest() are (I think) legitimate things in an Angular.dart acceptance test. The one other thing that I do to improve the test is to call in the scheduled_test library. I update the development dependencies in pubspec.yaml:
name: angular_calendar
  angular: any
  # ...
  scheduled_test: any
Then, I pub get the new dependency.

The scheduled_test package is unittest with some nice asynchronous support. The only incompatibility with unittest is the lack of a tearDown(). Instead of a tearDown(), I have to schedule what to do when the current test is complete. In this test, that means that I need to tear down the test injector:
      module((Module _) => _

The rest of the setUp() is exactly as it had been before—setting things up for Angular.dart dependency injection in test, injecting my application controller and backend service, along with a mock HTTP service and test bed.

As for the the test itself, I can schedule asynchronous tasks, which will be executed in serial, one-per “schedule.” This ends up looking like:
    test('Retrieves records from HTTP backend', 
      inject((TestBed tb, HttpBackend http) {
          respond(200, '[{"id":"42", "title":"Test Appt #1", "time":"00:00"}]');


        schedule(()=> http.flush());
        schedule(()=> tb.rootScope.$digest());
            contains('Test Appt #1')
That… is very pretty.

The http.whenGET() and tb.compile() could just as easily move into another setUp(). Even here, they are so compact that they hardly seem out of place.

After the setup, I schedule the http.flush() and scope.$digest() that I determined were necessary Angular.dart things under test. The last schedule is to set my expectation. Compact. Easy to read. Full browser stack, acceptance test. I like it!

Day #921

No comments:

Post a Comment