The JADE 2022 release meets tomorrow’s business demands.
Guest
|
HistoricalComments
Brian Johnstone 27/07/2018 3:50:51 PM
For our Unit Testing we either add unit testing specific 'getter/setter/wrapper' methods on the subschema copy classes in the Unit Testing schema or we use combinations of 'get/setPropertyValue' and 'sendMsg/sendMsgWithParams' to get/set/execute protected properties/methods respectively. Either way, it means when viewing the classes outside of the Unit Testing subschema there is no 'pollution' of the view with things added solely for Unit Testing purposes and you can still leave things 'protected' for encapsulation purposes. Kevin Saul 10/07/2018 2:17:38 PM With regards unit tests in particular .. there's also been some internal debates in the past about keeping features protected for encapsulation vs. making them public for the sake of unit tests. It'd be useful if unit tests were allowed to access/test protected features, so we didn't have to change how we'd otherwise prefer encapsulate behaviour. Kevin Saul 10/07/2018 2:12:52 PM Perhaps a "Sort By Visibility" option would be simpler? Where the most accessible features would be listed first (still sorted by name), with least accessible features shown last. In the past, we've had conventions where we prefixed a protected method with a z to keep it at the bottom of the list, but this is a work-around which falls apart when you want to change the access of an existing method. |
