Please log in to watch this conference skillscast.
Recently, I've seen several systems with test code that is intended to be "business facing" but that, in practice, is just getting in the way. The test code is bloated and repetitive, and the language of the tests doesn't really explain the original intent.
The tests that I see often remind me of a previous attempt to allow non-technical people to work with computers: Cobol. The features that helped to make it hugely successful, its "English syntax" and flat structure, are also barriers to abstraction and modularity--the techniques we need to cope with scale. Is writing everything out in full the only way we can get our point across?
YOU MAY ALSO LIKE:
- Jenny Martin and Pete Buckney's BDD From Start to Finish - Successful Delivery through Continuous Collaboration (in London on 27th - 29th March 2019)
- Uncle Bob Martin's Clean Code Workshop on Agile Software Craftsmanship (in London on 11th - 12th April 2019)
- Uncle Bob's Clean Code: Agile Software Craftsmanship (in London on 30th September - 2nd October 2019)
- P3X - People, Product & Process eXchange 2019 (in London on 31st October - 1st November 2019)
"Given When Then" considered harmful
Steve was a pioneer of Agile software development in the UK, he has built applications for banks, ISPs, financial data providers, and specialist software companies. He has given training courses in Europe, America, and Asia.