CITCON Europe last weekend proved again to be one of the best conferences for networking and keeping up with the developments in the community. The most important session for me personally was “Beyond Basic TDD”, an openspace discussion on the topics that people with a few years of TDD experience should learn to take the next step. Here are the ideas we discussed: Continue reading
Although Selenium is an essential trace element, it is toxic if taken in excess. That is what Wikipedia has to say on the chemical element Selenium, but pretty much sums up my feelings about the web testing tool of the same name as well. I like very much how easy it is to implement web tests with Selenium, but I’ve seen so many teams shoot themselves in the foot by misusing it and wasting a ton of time on writing and executing tests that simply got thrown away on the end. The Page Object pattern, popularised by Simon Stewart with WebDriver, seems to be the universally accepted best practice to manage UI tests efficiently and the preferred way to implement Selenium tests. However, at the recent CITCON Europe conference in Paris, Antony Marcano spoke against this and offered an alternative. Continue reading
The most important take-away idea from CITCON Europe this year for me was probably building ‘save game’ functionality as an integral feature in software systems.
Antony Marcano talked about this, not as part of the official programme but over beers which is another example of how informal chatting at conferences is often more valuable than the schedule. He mentioned how it is common for games to automatically save the complete state at checkpoints. This allows us to easily go back to the last saved position and continue playing if our character gets killed for whatever reason. So if something really bad happens after 10 hours of playing, you don’t have to do it all over again.
Functionality similar to that could help immensely with exploratory testing in software. When we find an issue, we could easily go back to the last checkpoint and reproduce it and also use that same saved game later to check if the problem was fixed. This could also be used if a customer encounters a problem in production to make bug reports a lot more complete and reliable.
Implementing this feature is by no means a trivial task and might be nearly impossible to retrofit into existing systems. The reason why gaming companies can do it is that they consider saving as an integral feature of their systems from start. I have yet to try this but my gut feel is that if a system is built with this in mind, the actual overhead of doing it is minimal. Modern games have states as complicated as lots of enterprise systems, with tons of actors, their states and event information at any time. Yet they manage to load it up in a few seconds and continue from the saved state. By designing for that up front, ensuring that all actors can be persisted and loaded and that all state is easily extractable, we should be able to do the same in enterprise software as well.
I facilitated an openspace session on acceptance testing and collaboration between business people, developers and testers at CITCON Europe last week. We started with a list of five common reasons why I’ve seen teams fail with acceptance testing but added five more during the discussion, so here’s an expanded top 10 list:
Last week at CITCON Europe Steve Freeman organised a session on mock objects focusing on the original ideas and what mock objects should be used for. Freeman started by disagreeing with the established view of mock objects as isolators for unit testing, advising developers to use mocks for object design and specifying responsibilities. Continue reading