The Ruby Craftsman
In my experience TDD is a guiding principle that produces better code that is a joy to write. There are several arguments for why the tradeoffs are not worth the benefit; I would like to address some of them here.
End-to-end testing, if you let it, will suck the life out of you. Tools like Capybara and PhantomJs provide an easy way to test from the user’s prospective. When I started using these tools initially I didn’t like how long they took to run. I thought then that if we could just make these tools faster they would be the best option to test a web app. Then I ran into other issues where sometimes these tests would be unreliable, failing at random times, making me feel uncertain of whether it was just the test’s flakiness or the new feature I had just added. So I would end up adding
sleepto give them a better chance of passing and sometimes I would end up deleting them because they were wasting my time.
When invoked with a block, yield all permutations of length n of the elements of the array, then return the array itself.
I have been discovering a new design pattern that leads to well designed interface and loosely coupled test. This design, as with many patterns, is not best in all cases but I found it very helpful on multiple occasions. I find the cases where it works best is when there is a deterministic algorithm.
This is a method I have come up with separate from the framework, rails, in making a json api. First why do you want to separate from rails? Rails changes and it deprecates api leaving difficult upgrade path for projects. Isolating from the framework also gives increased speed in testing. Rails takes time to load up and this will slow down the feedback cycle. The other perk is that the framework can swapped out for another with little effort. You may come to the conclusion that you don’t need Rails and move to something like Sinatra, although you most likely won’t.
subscribe via RSS