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.
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.
Published: July 29, 2014.
Next post in HappyPancake story: Data, Use Cases And New Module
🤗 Check out my newsletter! It is about building products with ChatGPT and LLMs: latest news, technical insights and my journey. Check out it out