Antony Denyer

I wanted to start looking at alternatives to our current set of cucumber feature tests. At the moment on the web team we’re using using FireWatir and Capybara. So I though I’d take at look at what was available in Node.js. Many people think it’s strange that a .Net shop would use a something written for testing Ruby or even consider something that isn’t from the .Net community. Personally I think it’s a benefit to truly look at something form the outside in.  Should it matter what you’re using to drive your end product or what language your using to test it? Not really. So what are the motivations for moving away from Ruby, Capybara and FireWatir? In a word ‘flaky’, we’ve had heaps of issues getting our feature tests, AATs and smoke tests reliable. When it comes to testing, consistency should be king. They should be as solid as your unit tests.  If they fail you want to know that for definite you’ve broken something, rather than thinking it’s a problem with the webdriver. [Read More]

Last Thursday a few of us from 7digital had a meet up with Sebastien Lambla author of OpenRasta. As some of you may know we’re been writing all our new API endpoint using OpenRasta, we have a vested interested in ensuring the success of this project and as such are responding to the rallying cry with gusto. [Read More]

One of the things we try and do is always keep our site up, sounds simple right? One way to achieve this is to have a good caching policy. Here’s what we do: [Read More]

Double-entry bookkeeping system A double-entry bookkeeping system is a set of rules for recording financial information in a financial accounting system in which every transaction or event changes at least two different nominal ledger accounts. At it’s simplest you have two ledgers when you make an account transaction you make an entry in both ledgers. Then at the end of the month you reconcile these two ledgers and they should be the same. Essentially from an accounting point of view we’re saying that by using two different ways of doing something we come to the same answer. Why is the useful from a TDD perspective? [Read More]

We’ve spent a lot of time recently on fixing up our automated feature tests (AATs). The problem has been that these failing tests have blinded us to real problems that have crept into live systems. The usual answer is to ‘just run them again’ and eventually they go green. The main problem is our attitude to the tests, we don’t respect them and we don’t listen to them, as such they provide no feedback and are completely pointless. The response to broken feature tests would normally range from the test environment is down, the data is in contention, the database is down etc etc, but never something I’ve done has broken something. So what is the solution? [Read More]