This is a re-post of my article over at Kabisa’s The Guild.
I’ve been busy rewriting Firefly for a while now using Hanami. Hanami is a fascinatingly fresh ruby web framework with a strong opinion on Clean Architecture. Me like!
Why test against different databases Initially I developed Firefly to use Sqlite for database storage. However, Sqlite is not always the best option. Running Firefly on Heroku for instance would be impractical, since Heroku’s architecture assumes you use a real database, like Postgres.
Ever since I started doing TDD I’ve used RSpec. It’s a great tool, and for a long time it was part of my standard testing stack. This stack also contains things like Cucumber and FactoryGirl.
Now, this stack works great. But that doesn’t mean it’s the best, it has its issues:
Cucumber Cucumber is, in almost every project, added complexity without any benefit. The idea behind cucumber is that it allows you to write your features / user stories in plain English and prove that those features are functional.
I have been working on an emulator for the MOS 6502 Microprocessor, written in Go. As part of this package I have also implemented a minimal 6551 Asynchronous Communication Interface Adapter. The 6551 provides serial IO and is easy to use in combination with the 6502.
When the microprocessor writes a byte to the 6551 it is stored in the tx (transmit) register where it’s available for other hardware components to read.
As a professional developer I test my code. Every check-in I do is tested either on Kabisa’s Jenkins server or on Travis CI Pro.
For open source projects there’s Travis CI. It’s free and a great way to get to know Travis.
Now, as an individual I have some side projects, most notably my own site, Ariejan.net. I value well written and well tested code as much for my own stuff as for my professional work.
Okay, let me clarify that title first. I, as most of you, have two sets of tests for my Rails application: rspec and cucumber. rspec heavily focusses on testing models and business logic while cucumber focusses on testing the entire application stack and user interaction.
The problem is that as your app grows, your test set grows - and so does the time it takes to run those tests.
I’m a happy user of RSpec, Cucumber and sometimes Steak. Great tools to write specs and features and prove my application does what it’s supposed to do. But sometimes I have the need for something more light weight. ~ For example, sometimes I need to write a single ruby method. Just something ‘quick’ to import a file, convert some data or whatever. Being a good citizen I want to test that method.