Delivering Features and Tests

Last week was quite productive and exciting.

Introduction of use cases into our development cycle worked out really well, helping to deliver tangible features in the absence of tangible UI to target (node.js front-end development is paused till Tomas gets back from the vacation).

These use cases so far:

  • serve as high-level behavior tests aligned with the domain language (compact and non-fragile);
  • drive development towards a better event-driven design;
  • produce nice human-readable documentation, as a side-effect;
  • provide really fast feedback cycle.

Actually, these use cases are the design. We can probably take them and rewrite the entire system in a completely different language in 2 weeks. And we can do that without loosing any features or scalability options.

However, these nice benefits are not as important as the fact the we spent last week developing new features and improving code coverage, while really enjoying the process.

Pieter jumped right into the game, picking up on use case development and extending the framework to support edge-cases which I missed (e.g.: testing file uploads or using real HTTP server to allow inspecting raw HTTP requests with WireShark). He already covered drafts module with use cases.

Pieter also invested time last week cleaning things across the code-base.

I spent the last week both adding use cases (coverage of chat, alerts, news, poll), fixing bugs revealed by them and adding proper handling of member-blocked and member-unblocked across the system.

As of now, we have 33 use cases covering 15 API calls. We know this number exactly, because of a tiny little helper command summary which can print out information about all use cases.

Image

With that command (and the power of BASH), one can easily answer questions like:

  • How many use cases are in the system?
  • Which URIs are not covered by the tests?
  • Which events are published or consumed by module X?
  • What are the dependencies between the modules?
  • Which events are not covered by any use case?

This self-building knowledge about the system is another reason which makes writing use cases so rewarding.

I also took a bite and tweaked our build server to include commit summaries in chat messages posted to Slack. This way, it is easier to observe team progress without going to git repository. This also encourages frequent pushes, since drone picks up only the latest commit in a push.

This week I'm going to continue delivering features, covering them with more use cases and also working on the ETL code to extract data from HPCv1 into our new system.

- by .