Skip to main content

Posts

Showing posts from August, 2014

Program for Change

We should program for change AKA the Open/Closed Principle. In my opinion, the OCP is one of the lesser respected SOLID principles. One of my biggest, and earliest failures fresh out of university was ignoring this concept.At the time I was applying YAGNI to some code myself and a couple of other developers were working on. After all agile methodologies promote this concept heavily. This made sense to me. My solution was to solve the problem with the minimal amount of fuss, however in doing so I strongly coupled the code we produced with the direct business requirements.The requirements stated that we would have three different types expenses. So I promoted that we model these three types of expenses directly. The UI knew about these expenses. The database knew about these expenses. The domain logic knew about these expenses.Everything worked well for a while. We finished early. We wrote just the code we needed. I was happy. Until the business requirements changed. The three types of …

Stop.Mocking.EVERYTHING

I've flip flopped on how to use mock objects since 2008. It's took me nearly five years to finally claim to have a solid, practical answer on what is in my opinion, their correct use.Mock EverythingSome developers told me to mock everything. Every. Single. Collaborator. I wasn't sure about this approach.My tests felt too brittle - tied to implementation details.My tests felt like a duplication of my production code.Your test count rises rapidly.This style of testing will slow you down - more to write/execute/debug.Mock NothingSome developers told me to mock nothing. Sometimes I never used mocks. I wasn't sure about this approach either.My tests felt too loose - it was easy to introduce bugs or defects.My production code suffered as I introduced accessors only for testing.No wonder I was confused. Neither approach seemed to be comfortable with me.SolutionUse mocks for commandsUse stubs for queriesThis halfway house is built around the idea of command and query separatio…

Acceptance Testing need not use the Full Stack

Joined a team with thousands of unit tests (~10k)But bugs still got through our QA processHow could this be?Team had a small number of full end to end live service testsSo my answer was to just increase the number of theseSurely this would solve our problem?Not quiteThe maintenance of these tests were a great burdenEach day many tests would fail, but nothing would be "broken".Data would have changed in the DBThe UI could have changedThe browser could have been slightly slowerAnd so onSolutionDelete the majority of live service tests - limit the tests to the core user journey through the applicationAs long as the pages load up, without an error we shouldn't careStopped testing logic or behaviour - made the tests loose, e.g. as long as value is not null or empty we are OK, we don't actually care what the value is.Made use of contract testing to substitute boundaries with in memory fakes, e.g. persistent storage. This allowed fast, stable acceptance tests to be run agai…