LSA Course : "Self Testable" Case types
Hello,
In the LSA course, a certain design pattern is used 2 times to make a case " self testable" by using a conditional stage when the case is supposed to be used as a child case.
I'm having a lot of trouble understanding why this is a good design.
First it makes it so that any built-on application has to override the pyDefault Case Type rule. Second It honestly does not bring any value compared to making a separate case type with the purpose of testing.
Are there other reasons that make this design viable?
Kind regards.
Accepted Solution
Updated: 3 May 2021 7:35 EDT
Pegasystems Inc.
US
@baeywAn application built on another application typically does override the case type rule in built on application using direct inheritance. You have to go out of your way to withdraw or remove the generated case type rule. Now that Pega has added a Create stage in version 8.5, having a test-only stage is arguably more cumbersome. The main advantage of having a test-only stage is that have one promotes speedier development but, as you said, there are other ways to test, as well. Within the 8.5 Booking solution, there are separate COE-level, Dev-Only, test applications, namely FSGSample and FSGSample2.
This works well. But then, the only case type that FSG COE owns is the Email case within the FSGEmail component application.
The decision was made to leave the test-only stage within the FSGEmail application for 8.5, not remove it. The Email case is strictly intended for use as a subcase.
It made sense to develop the Email case type by having it create an Email child case.
All in all, there are more advantages not having a test-only stage, than having one, better to use one or more separate DevOnly test applications. In production case type should not possess a test-only stage.