Eventide supports test-driven development beautifully, and TDD helps drive home the aspects of the design. Let’s pretend we were writing the handler for the Build command in the [composite-component](https://gitlab.com/such-software/do-expensive-things-once/composite-component) I built for the Utah Microservices Meetup last year.
This component makes stitches together video clips retrieved from fictional IoT cameras into a… wait for it… composite video. Clients send the Build command to kick off this process.
We typically use TestBench when testing Eventide components, but Eventide as a framework has no opinion on the matter. I have an opinion on the matter, but I’m not Eventide. It’s a framework, and I’m a human. Not the same thing.
Anyway, in the typical Eventide component, you’ll find a test/automated/ folder. It holds tests that are automated. This is in contrast to tests that are not automated, which you’ll find in a test/interactive folder. Those are test files you run and as a human observe the results.
I haven’t seen folks using Eventide try to make the distinction between unit, integration, functional, whatever tests. I’ve seen lots of other people try to make the distinction, and if you ask 3 developers what a unit test is, you’ll get 4 answers. Automated vs. interactive is fairly easy to tell the difference.
When writing automated tests for software that has message handlers, you will probably be shocked to learn that there are tests for those handlers. We’re writing command handlers, so we add a handler for those tests, ending up with test/automated/handle_commands. If we were writing a handler for an event, can you guess what we would have named the folder?
The next step in the directory structure is for the command that we’re handling. Build is our command, so we snake_case that end end up with test/automated/handle_commands/build, and it’s under here that we put our test files. We put a test file for each scenario Don’t take “scenario” as an important word that you need to replicate. I’ll explain what I mean, and then you can decide if you like that word.
The first scenario we’ll write is the case where handling the case where it’s the first time we’ve handled a particular Buildcommand. We name this test file after the event we expect to be written as part of processing the message in question. In this message flow, Initiated is the event we expect to write, so we create a file at test/automated/handle_commands/build/initiated.rb.
We’re pushing against the two-minute limit for this email, so I’m going to call it here. This process may really have been better as a video. Tell me if you think so, but I was expecting this one would be a series.
See you next time.
