Finding a good development partnerKevin Poorman

Principle Architect

@CodeFriar

Place

Customer or

Partner logo in

white area of

slide, centered

Kevin PoormanPrincipal Architect

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

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.

Terms and Conditions

•Single Framework Structure

•Test Coverage

•Assertion

•Comments

Terms and Conditions

Single Framework Structure

Sin

gle

Trigger

Calls class method(s) A

Calls class method(s) B, C and F

Calls class methods X, Y, and A

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

Terms and Conditions

Test Coverage

75% 85% 95%

Minimum

Requirement

to deploy

Rest easy at

night

Psychopath

never looks

up your

address

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()

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.

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 // & /* */

What to look for in a good development partnerCoding 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.

What to look for in a good development partnerTesting 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%

What to look for in a good development partnerTrust 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.

What to look for in a good development partnerTrust but verify

– When reviewing test classes, you should read through them, not necessarily for comprehension,

but to ensure that they are firing assertions.

What to look for in a good development partnerTrust 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

What to look for in a good development partnerTrust 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.

Comments Test Coverage Single Triggers Test Data

Top of Every File 85% or higher aggregate 1 trigger per objectAll tests generate their

own Data!

Above every method85% or higher on all new

classes

Uses an established

Trigger frameworkUse 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 StandardsMy opinionated requirements.

Use to

introduce a

demo, video,

Q&A, etc. Questions & AnswersIf you don’t ask questions … I will.

Questions & Answers