Test Driven Development for Siebel
Unit testing is something that I always want to attain perfection in, but almost never do. Not delving in the challenges/resolution action in the process/ execution in a packaged product implementation scenario, I want to take this article in a different direction – test driven development for Siebel.
Test driven development is not new; it started as a concept of extreme programming where the developer tests continuously during development. Developers start their development process by writing the test cases, execute test cases before the onset of the development process itself and continue to run test cases at identified milestones in the course of development. The initial run of is expected to fail, if the test execution passes the first run then the feature already exists in the system and no development is required.
Now, the objective is something that all of us sane folks agree to with a few exceptions. But the bigger problem has been Siebel. With its HI technology running on ActiveX controls, the automation always proved to be brittle and hard to maintain. The situation in the automation regression space improved with the introduction of better integration of Siebel objects with Mercury test tools, but that is a hard sell for TDD since that (in most probability) requires a separate team to write test cases. What we need is something on the lines of JUnit in java, which provides a simple way to write small test cases for the small modules that developers write and provide a way to test them. There are people who have attempted to do something in that area, but that provides a limited coverage for business rule testing.
I see OpenUI as a big game changer here. In a period of 2-3 years (provided Siebel is alive), we should see at least a couple of tools that could aid in development of better code using the TDD approach. Till then the approach cannot be applied across the application, but could be used in a limited fashion.
- Identify the business logic in form of workflows, scripts, data validation manager or BRP that needs continuous testing during development
- Write client business services that build test data and test the said logic as per the requirements
- Start the actual development process. Execute the client business service periodically to ensure that the development stays on path
The client business service could easily be replaced with a more generic java / COM program that tests a given entity. Any BRP, DVM, complex workflows, business service scripts should be the targets for such a process.