I ran force.com security scan on my managed package i got the following report

Query: Test Methods With No Assert L 4: @testSetup static void defConnSetup(){

so is it necessary to add assertion in to the test setup as well?

2 Answers 2


No, you don't need to include Asserts in @TestSetup methods.

You could make a note of the fact that this is such a method in your False Positives document that should accompany the security scan results though.

I don't think we actually even do that any more as the security team will be familiar with this scan result, but as a best practice, I don't see the harm in including a note in the False Positive doc.

Note: If you really did want to make your code look super stunning great, I guess, after @testSetup you could "query" back any inserted data and assert that the correct number of rows now existed?! There's a thought.

  • 1
    Except that the limits you consume in your TestSetup methods count against you in all your testMethods, no? Somewhat of a drawback.
    – Adrian Larson
    Jan 5, 2017 at 13:58
  • 1
    Well, only towards your test setup governor allowance, which other than this probably shouldn't include much SOQL itself either. You then use Test.startTest and Test.stopTest to correctly asses the limit usage of your target functionality. Jan 5, 2017 at 14:11
  • I'm familiar with the new set of governors between those methods. :) I guess it's an edge case that you would be so near the SOQL limit in a testMethod that one more in your @TestSetup would push you over the edge.
    – Adrian Larson
    Jan 5, 2017 at 14:13
  • 3
    @SimonLawrence Every unit test I write has a test method that validates my test data is setup correctly. Here's the Gist that actually works as a template in Eclipse. This design pattern protects me when a new validation rule or required field gets added. Jan 5, 2017 at 14:44
  • 1
    Outstanding @JohnThompson! I gave a presentation at LondonsCalling last year on testing in which I advocated asserting your conditions before even running the actual test code... cuts down debugging/failed test issues down the line hugely. It's a great practice. I love the idea of having a singular test method exclusively to asses the @testSetup though, rather than having assertions in the test setup as it will indeed reduce the repetition of checking testSetup each time each method calls it (I shall implement that as a pattern here at work for the rest of the team - with credit to you!) Jan 5, 2017 at 14:58

The missing assert rule for Checkmarx is a quality rule, not a security rule. Quality rules are not relevant for the security review -- you can run the scan to be security rules only if you want.

Also this issue is a false positive and will be addressed in the next release of the scanner (3.2).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .