Not all Development partners rock... here's how to find a good one.

1. Finding a good development partner
Kevin Poorman
Principle Architect
@CodeFriar

2. Kevin Poorman
Principal Architect

3. Agenda
•Why you need a good development partner
•Terms and Conditions
•What to look for in your partner and in the code
•Questions, Comments and Snide Remarks

4. Why do you need a good development partner?
•Strategy v. Tactics
•Code is strategic by nature.
•Cost of maintaining code is always the largest expense
of a software project. (cf. Code Complete, by Steve McConnell)
•In other words, you want a developer who writes code
as if the person who ends up maintaining it is a violent
psychopath who knows where they live.

5. Terms and Conditions
•Single Framework Structure
•Test Coverage
•Assertion
•Comments

6. Terms and Conditions
Single Framework Structure
SingleTrigger Calls class method(s)
A
Calls class method(s)
B, C and F
Calls class methods
X, Y, and A

7. Terms and Conditions
Single Framework Structure – Why you want this!
• This allows you to set the order of operations for your trigger code!
• Makes it far easier to test!
• Much easier to follow the code down to where a problem may be

8. Terms and Conditions
Test Coverage
75% 85% 95%
Minimum
Requirement
to deploy
Rest easy at
night
Psychopath
never looks
up your
address

9. Terms and Conditions
Assertions
• Until we have Siri in Salesforce, we can’t just ask if our code is working right.
• We use assertions to tell Salesforce what the expected response is
• We could, for instance, assert that Dreamforce14 = Awesome when we run
code that asks is Dreamforce14 Awesome?
• Three Assert methods:
• Assert()
• AssertEquals()
• AssertNotEquals()

10. Terms and Conditions
Assertions
Tests without Assertions are wasted money. You’ve paid someone to write them
so you can deploy, but their purpose is to prove the code works as expected.
Having tests without asserts is the new buying a picture frame and never
replacing the example family photo that came with it.

11. Terms and Conditions
Comments – what the what?
• Comments are how developers leave notes to future psychopaths, admins and
anyone else brave enough to venture into the code.
• Two flavors of Apex code comments // & /* */

12. What to look for in a good development partner
Coding Standard:
Written document describing how the code will be written:
– Good:
• Defines what is to be tested, what “dialect” will be used, and what / how code will be commented
– Better:
• Also describes naming conventions for files, classes and methods
• Provides example comment blocks & establishes rules for a single trigger per object, with all trigger logic in
classes!!
– Best:
• Additionally describes code coverage requirements and specifically mentions that tests will include
positive, negative and permissions based tests.

13. What to look for in a good development partner
Testing Standard:
Written document describing how the code will be tested:
– Good:
• Defines a minimum requirement of 80% code coverage. (Why 80%? Because you probably inherited some
badly tested code!)
– Better:
• Also requires that all tests generate their own test data and that no tests use @seeAllData
• Enforces no i++ tests
• Increases the minimum code coverage requirement to 85%
– Best:
• Additionally demands that all test methods call at least one Assertion
• Requires a minimum code coverage of 90%

14. What to look for in a good development partner
Trust but verify
– Your Coding standard should specify naming conventions for files and classes, and as such you
should be able to easily identify your test classes and what they’re testing.

15. What to look for in a good development partner
Trust but verify
– When reviewing test classes, you should read through them, not necessarily for comprehension,
but to ensure that they are firing assertions.

16. What to look for in a good development partner
Trust but verify: SeeAllData will hurt you when you least expect it.
– As you can probably imagine, the @seeAllData annotation allows your test to access all the data
in the org you’re running the test in.
– This is a bad thing. (repeat after me) This is a bad thing!
– More often than not, this results in tests *expecting* data to be present in an org.
• If the data is only present in one org… the test will fail in other orgs.
– Instead, each test should create and insert it’s own records.
– Almost never truly needed

17. What to look for in a good development partner
Trust but verify: Faking Code Coverage
– You can fake code coverage. You shouldn’t. You shouldn’t allow the very concept to be floated in
your presence. This is generally done by creating a class with a method that consists of nothing
but lines incrementing a given variable. Ie: i++; for a long time, follwed by a quick test method
asserting that I = 3000;
– Tar and feather developers you’ve found who do this. It only serves to foster a false sense of
security.

18. Comments Test Coverage Single Triggers Test Data
Top of Every File 85% or higher aggregate 1 trigger per object
All tests generate their
own Data!
Above every method
85% or higher on all new
classes
Uses an established
Trigger framework
Use a TestFactory Class
Around any complex logic
blocks or apex-shorthand
CodeCoverage report
card with each code
submission
Clear and concise
comments on how triggers
Custom Assertion
methods –
Assertions.recordDidFailV
alidation()
You should be capable of
reading the comments in
the file and following the
flow of data
Verify coverage in the
Developer console.
Trigger logic classes are
bulk tested
Positive, Negative and
Permissions based
testing.
Coding & Testing Standards
My opinionated requirements.

19. Questions & Answers
If you don’t ask questions … I will.
Questions & Answers