If there is one thing more frightening than mapping your way through a maze of twisty little libraries, it’s getting mired in the framework swamp.
Refactoring should never appear as a task on a schedule. Keeping code clean is just something that you do all the time.
We’ve got a lot of scrum out there but only 50% of them are doing iterative development!
Registration is on the XING Group of DNUG Bern.
Thanks to the organisators for inviting me.
Marcus blogged about using ATDD in projects of rewriting legacy applications. He describes the problem of missing business involvement in those kind of projects.
He describes a possible approach for a project like this and a technical setup how to bind formalized examples (scenarios) to the new application.
What I miss in his explanations is any advice how to get from the legacy application to the formalized examples (scenarios). In my experience that is a very important aspect and I am afraid that many developers ignore or underestimate the importance of this for the whole BDD process!
Finding the relevant examples, formalize them in a maintainable way that can drive the development process and formulating them in a business readable language is is a lot of work and has to be justified and has also to be made transparent to stakeholders.
I would ask: Is the business involved in this process at all? Is any stakeholder except the developers interested in those examples at all?
If the answer to those questions is 'no', I am not sure if it makes sense to take the effort to go for scenarios in a business readable format. (note that I still think formalized examples do make sense, but not in a business readable format)
The real value of business readable examples lies in the discussions between stakeholders they provide a base for. They should be the baseline for prioritizing and re-thinking the functionality of the application. If there is no chance of involving business, they loose pretty much all of their value.
Business readable examples have to be an artifact that business cares about! Else there is the imminent risk that the whole BDD effort degrades to a petty effort of over-eager developers (I have been one of those, believe me).
In this scenario the reference/acceptance criterias are definied by the existing application. Reverse engineering into plain-text examples does not necessary provide enough value in my opinion.
In my opinion in this scenario it can be more efficient to just write high level user stories and reference the legacy application for the acceptance criterias.
Of course if access to the legacy application is not easily given for every developer or if the provided instance of the legacy application does not illustrate all behavior (for instance because the test-dataset is not representative), then specifying behavior with examples gets more attractive again.
Gojko mentioned also an interesting approach by Lisa Crispin. She promoted to write tests first against the old application and then use those tests as examples for driving the implementation of the new application.
I came across this approach before (probably in Agile Testing) but I never considered it for my projects.
I am wondering how applicable this approach is. Do you automate the tests also against the old application? Probably writing scenarios in plaintext would be enough. Automation does only make sense for the new application.
Last week Gaspar and I held two workshops at the Skillsmatter Progressive .Net Tutorials in London:
Gaspar and Christian have each written a summary here and here.
Altogether I think the workshops were quite successful and the feedback from the audience was very positive. However when I watched the presentations online I was shocked by my bad english. I definitely need more practice ...
The presentations are available online:
