So given the above, the forces I am trying to balance are
- Make it easy for people to do the right thing, hard to do the wrong thing.
- Make it valuable (Finds more bugs than false alarms)
- Make it resilient (Allows me to refactor like the true crazy person I am)
- Make it fast (Magnify it’s value rather deminishing it)
- Make it good enough (Give me enough confidence to do more crazy stuff but don’t become dogmatic)
- Allow people to do what they are good at
Next I’ll talk about how the default setup I use to do, in-memory, out of container testing.
(Previously on TWSDEV)
As the “crazy” guy behind the in-memory / out-of-container acceptance testing on a number of java/.net projects, I think it’s important I explain to people the “Why” and the forces / constraints I am trying to balance. But first I want to quickly lay down my beliefs and values:
- I believe in testing as much as possible (UI included)
- I believe tests must add more value than they cost (Measure it!)
- I value tests that are fast and are resilient to change more than tests that take a long time to run and are brittle.
- When refactoring a feature I value acceptances tests and integration test over unit tests.
- When designing/exploring a new interface / object interaction I value unit tests over acceptance tests to help guide me.
- I believe that QA’s are so much better at finding bugs than DEVs but worse at writing code / abstractions
If you have met me or worked with me in the last 15 years or so, you will know that I am pretty mad about the web as a platform, HTTP as a protocol and HTML as a state engine. Add to this the last 6 years or so practising agile techniques while building highly scalable websites and you tend to find that I have fairly unusual views in the field about how to build and architect web applications.
A lot of people say to me,
Dan, you must write about X as the industry seems to be doing Y and while I find it very easy to talk in a face-to-face conversation or even a mailing list, writing an article or post has always been a challenge due to the one way nature of the conversation. Anyway after some gentle nudging by Sarah Taraporewalla, Christian Blunden and Martin Fowler I have decided to jump in head first and try and create a series of articles that will hopefully open a few peoples eye’s to some alternatives.
So enough with the why and onto the what I’m planning to cover in the series:
- Caching on the wire not in the app
- Addressable components
- Personalisation, cachability and composition
- Moving state off the web server
- Web server decoupling, in-memory testing and lightning fast builds
- Some alternative libraries
- Common HTTP patterns