Test Driven Model Development
I had a great conversation with a colleague (thanks Andy) recently regarding BPM technology and the software development lifecycle. We were lamenting the fact that whenever a new development paradigm comes along, we run the risk of taking one (or more likely many) steps backward in our SDLC technologies.
Take, for example, test driven development (TDD). (Aside: I enjoyed the latest ARCast on TDD from Ron Jacobs.) How do you unit test when doing model driven development as is the case in most BPM tools? What are the appropriate “units” to test? For that matter, how does a continuous integration model work? Can the models be stored in a source code management system like Java or C# code? Can I run automated builds? Does the concept of a “build” even apply anymore? I have a hard time believing that the use of these new model-driven tools somehow negates the need for testing and continuous integration. It would be great to hear more on how the best practices we’ve learned in writing large systems in Java and C# now apply when programming through pictures from some of the vendors in the space. I don’t know whether any of the vendors have given any thought to this, but I have seen organizations that have run into some of these questions as they adopted BPM technologies. Anyone have some answers?
Update: InfoQ posted some similar thoughts under the heading, “Why do Java developers hate BPM?”
2 Responses to “Test Driven Model Development”
Leave a Reply
[…] in November, in my post titled Test Driven Model Development, I lamented the fact that when a new development paradigm comes along, like the graphical […]
[…] focused on modeling, not deployment or execution. Admittedly, that last part is slowly changing, but as Biske previously pointed out, it would pay for these folks to pick up a few of the lessons learned by the development community […]