Intentional software, WYSIWYG and testing
Charles Simonyi has blogged about some parallels between what they are doing at Intentional and the development of WYSIWYG. It's an interesting read, in particular the familiar idea that change in software often creates problems - we've all fixed one bug only to introduce another. However I think we have a solution to that problem already, test driven development. If I write tests first and then change something I have the safety net of a failing test to tell me I broke something.
If we make our acceptance tests express the intentions of the business person we can verify both that our code is behaving correctly and also that it captures the correct intent. This can be as simple as giving our tests meaningful names or something like Behavior Driven Design which is a more evolved form of the same idea.
All sounds nice huh? However when we look at more complex applications and in particular some of the acceptance tests things come a bit unstuck. I've seen projects where the complexity of the acceptance tests becomes a barrier to change, and they are all to often in a form a business person can't understand let alone express an intent in.
Of course this can be because someone didn't make the economic choice of just testing things manually, sometimes thats just cheaper and easier. On the other hand if I had a tool which let business people easily capture their intentions as tests.....Of course nothing new with this kind of idea, Martin Fowler mentioned something similar an age ago, we also found ourselves writing java code akin to a DSL for expressing acceptance tests on a recent project.
If we make our acceptance tests express the intentions of the business person we can verify both that our code is behaving correctly and also that it captures the correct intent. This can be as simple as giving our tests meaningful names or something like Behavior Driven Design which is a more evolved form of the same idea.
All sounds nice huh? However when we look at more complex applications and in particular some of the acceptance tests things come a bit unstuck. I've seen projects where the complexity of the acceptance tests becomes a barrier to change, and they are all to often in a form a business person can't understand let alone express an intent in.
Of course this can be because someone didn't make the economic choice of just testing things manually, sometimes thats just cheaper and easier. On the other hand if I had a tool which let business people easily capture their intentions as tests.....Of course nothing new with this kind of idea, Martin Fowler mentioned something similar an age ago, we also found ourselves writing java code akin to a DSL for expressing acceptance tests on a recent project.
0 Comments:
Post a Comment
<< Home