Documentation_Testing_2 - revaturelabs/assignforce-force GitHub Wiki
How Testing works / How to write tests
All test classes, methods, and their helper classes must be preceded by an @isTest tag in the line above. This ensures that the class and method are parsed and run as tests, and so that code coverage doesn't check that they be covered by tests. There is also the @TestSetup tag. It is used to annotate a test class' setup method, which is used to perform any DML statements that will run before every test in the class. Apex classes are tested by dedicated test classes of the same name, but with "_Test" appended at the end. Therein lie test methods corresponding to the methods of the tested class, following similar naming convention of imitating the tested method's name but with the word "Test" added.
These individual unit tests' logic can be thought of as consisting of three sections: Arrange, Act, Assert (the AAAs of testing). The Arrange section is where variables are declared and testing data is defined. If all tests in a class share common DML operations in their Arrange section, these should be moved over to the test setup method (annotated "@TestSetup") which runs before all unit tests in the class. The Act section is where the action or behavior that is being tested is executed; this usually consists of running the method the unit test is covering. The Assert section is where System.assert methods verify that the behavior being tested acts as expected and determine the outcome (pass/fail) of the unit test.
There is some behavior that is common to multiple test classes. This is implemented in the utility classes like UtilityMethod and CreateAssignForceData, so that all test classes that use that common functionality can call it from the utility classes rather than repeating code in multiple test classes.
Utility Class / Create Assign Force Data .cls
The utility class contains methods for creation of test data and is utilized in test methods either via static reference or including the code itself in the test setup.
The CreateAssignForceData.cls contains methods that will populate the org with data for hands-on testing within the app. To create the necessary records, call the methods anonymously. The utility class can also be utilized in the same manner, except the creation of users is limited by licenses in production, so creation of users must either be facilitated manually, or a new method could be written that creates users and then in a subsequent transaction deactivates the user, as a user can not be inserted as deactivated.
Coverage
Currently all Apex classes are 100% covered by tests which account for multiple test cases (e.g. positive, negative, edge-cases, etc.). Javascript code for Lightning components is not currently covered; it requires a different approach to testing than using the Apex testing framework.
It is also worth noting that the UtilityMethod and CreateAssignForceData classes are annotated with the @isTest tag. Even though they do not have any unit tests of their own, it's important that they be marked as test classes. Otherwise the Apex test framework will think that these are classes requiring testing and count them towards the code coverage metric. This would really skew the result of that metric, which could mislead us to believe that we have far more code coverage than we actually have.
Classes currently covered by testing:
- afApproveButtonExtension
- afAvailListContainerApexController
- afBatchesListViewTableExtension
- afExtTrainersTabListViewApexController
- afExternalTrainerBatchesApexController
- afNewBatchAndAvailabilityApexController
- afNewBatchFormApexController
- afNewTrainingTrackTriggerHelper
- afPTOTabsApexController
- afRejectButtonExtension
- afTimelineController
- afTrainerInfoController
- afTrainersTabListViewApexController
- afTrainersTabPTOApexController
- afTrainingBatchesApexContorller
- afTrainingTriggerHelper
Specifics of any given test class and the test cases therein can be found in the comments of the test files themselves.
Future Implementations
The intent is to maintain 100% code coverage for Apex and Javascript code while also accounting for all categorically different test cases. For Apex, this means updating and adding tests as existing code is modified and as new functionality is implemented. For Javascript, this entails writing an entirely new suite of tests to cover that section of functionality. Javascript tests should follow the same practices as Apex tests (naming conventions, AAA, accounting for multiple test cases), albeit using the Lightning Test Service instead of the testing framework for Apex.