declarative-lookup-rollup-summaries
declarative-lookup-rollup-summaries copied to clipboard
Test Methods With No Assert
The Apex Test Methods do not Assert that the code behaves properly. Verifying that your code works as you expect it to work is the most important part of unit testing. It is important to ensure that all test methods use the System.assert methods to prove that the code behaves as expected. If you do not use any System.assert() method calls, then the tests are not verifying results properly. References: https://wiki.developerforce.com/index.php/An_Introduction_to_Apex_Code_Test_Methods https://wiki.developerforce.com/index.php/How_to_Write_Good_Unit_Tests
I just poked through a handful of the test classes and they do have asserts. What test class are you specifically saying isn't using asserts?
dlrs_AccountTest (standard object)
`/**
* Auto Generated and Deployed by the Declarative Lookup Rollup Summaries Tool package (dlrs)
**/
@IsTest
private class dlrs_AccountTest
{
@IsTest
private static void testTrigger()
{
// Force the dlrs_AccountTrigger to be invoked, fails the test if org config or other Apex code prevents this.
dlrs.RollupService.testHandler(new Account());
}
}
dlrs_PolicyTest (custom object)
/**
* Auto Generated and Deployed by the Declarative Lookup Rollup Summaries Tool package (dlrs)
**/
@IsTest
private class dlrs_PolicyTest
{
@IsTest
private static void testTrigger()
{
// Force the dlrs_PolicyTrigger to be invoked, fails the test if org config or other Apex code prevents this.
dlrs.RollupService.testHandler(new Policy__c());
}
}
Yeah it passes the rollup into test classes built into the package where all the asserts live. This allows the package to generate test dynamically as there are infinite dlrs records/triggers that people could create. If you go into the test classes that are namespaced with dlrs you can see the bulk of the test code that is run.
On Oct 27, 2017 6:52 PM, "jschneider-nexgen" [email protected] wrote:
dlrs_AccountTest (standard object)
`/**
- Auto Generated and Deployed by the Declarative Lookup Rollup Summaries Tool package (dlrs) **/ @IsTest private class dlrs_AccountTest { @IsTest private static void testTrigger() { // Force the dlrs_AccountTrigger to be invoked, fails the test if org config or other Apex code prevents this. dlrs.RollupService.testHandler(new Account()); } }
dlrs_PolicyTest (custom object)
/**
- Auto Generated and Deployed by the Declarative Lookup Rollup Summaries Tool package (dlrs) **/ @IsTest private class dlrs_PolicyTest { @IsTest private static void testTrigger() { // Force the dlrs_PolicyTrigger to be invoked, fails the test if org config or other Apex code prevents this. dlrs.RollupService.testHandler(new Policy__c()); } }
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/afawcett/declarative-lookup-rollup-summaries/issues/581#issuecomment-340131632, or mute the thread https://github.com/notifications/unsubscribe-auth/APXKqmgBJvHCSkdpVbCBEFh6og7L_iTWks5swojCgaJpZM4QJvzT .
Yes, @DanDonin is spot on, in this case the packaged tests assert the quality of the code, not this generated test. Adding asserts to the generated test code in this case would also be challenging, since there is no way to setup all the required data automatically without knowing the use case. At @jschneider-nexgen does this help as regards your original need? Is someone querying you on this? We might be able to add comments to the tests or a fake assert to keep code scanners happy?
The problem I run into with it is when a client runs the Force.com Source Scanner Report (http://lp.checkmarx.com/salesforce/) (https://security.secure.force.com/security/tools/forcecom/scannerhelp) and asks about these test classes. Personally, I get it, but a fake assert would likely resolve this and prevent the conversation.
Ah see, they must have install the code unmanaged then, rather than as a managed package? Otherwise the Source Scanner would not see the test code. Happy to flag this as an enhancement though.