Hi Vijay. Thank you for your response. I agree with you that automated testing is very important for code quality, and what you describe – generating the documentation by running the tests – could have been a choice. Actually, that was even what I did in an early version.
However, right now, the project is about more than just generating the requirements documentation. It is about controlling the flow of the application with the same code as well. That’s the nice thing about it. You don’t need to implement the control flow twice, once in production code, and once in the test. The use case model can be used in BOTH test and production code. There is a TestUseCaseModelRunner that can – and should – be used in automated tests.
That actually can make system acceptance tests a lot simpler – because you don’t need „glue code“ that translates from your tests to your production code. On the other hand, by using requirmentsascode, you would sacrifice some freedom in your production code, and yes, you would need to update the use case model if something in the high level, user visible behavior changes. But not if some low level, component internal thing changes.
So I guess that’s a trade-off you need to make.