It’s MediaWiki Documentation Day 2017!
So I’ve been documenting a couple of things, and I’ve added a bit to the Xtools manual.
The latter is actually really useful, not so much from the end-user’s point of view because I dare say they’ll never read it, but I always like writing documentation before coding. It makes the goal so much more clear in my mind, and then the coding is much easier. With agreed-upon documentation, writing tests is easier; with tests written, writing the code is easier.
Time for a beer — and I’ll drink to DFD (document first development)! Oh, and semantic linebreaks are great.
I’ve been writing lots of integration tests lately, for a system that has zero unit tests. Does this make me a bad programmer? Probably. But it’s so easy! This is in Kohana, using ORM, and so the model basically is the database (which idea I rather like), and mocking it or splitting it out to be separate is just a pain. Far less code to write if one can test the whole interaction of the system at once.
I am being slightly tongue-in-cheek here, because I do realise that the maintenance burden of a system built with tight coupling between the various layers is likely to increase contiunually (to a point where someone at somepoint says “oh sod it, let’s rebuild from scratch on Drupal”). But for the multitude of systems that are basically just CRUD, the approach of writing tests that mimic the code seen in controllers is pretty simple and neat.
In Kohana (with Minion), actions and tasks are sort of similar. Both should be ‘thin’ and do nothing more than create objects of the domain model, and direct bits of those objects to various systems of output. Keeping them both in my mind today is helping me divorce the domain model’s interface from the usual web-based interaction: if I imagine that I’ve got to do the same things in both a web-based action, and a terminal-based task, then they seem to end up thinner.
Testing comes into it as well: the test method (I mean the
do_a_thing_test() method, not the method-of-testing) is again similar to the actions and tasks. It mustn’t know much or do much. It only differs in that, in place of setting up some sort of output, it makes assertions about the domain objects.