On October 23rd, 2014, we updated our
By continuing to use LinkedIn’s SlideShare service, you agree to the revised terms, so please take a few minutes to review them.
How to add exceptions Step two : Give each member of the team two cards. Go over the list of rules with the team and have them vote on them. Voting is done using the cards where:
No cards: I think the rule is stupid and we should filter it out in the findbugsExclude.xml
One card: The rule is important but not critical.
Two cards: The rule is super important and we should fix it right away.
David from testdriven.com via Eishay
How to add exceptions II
Add the exceptions you want
No oversight, no questions asked
Lets you be strict with rules
Makes you consider whether adding the exception is right
Where do exceptions go?
All in one place
Most of our tests
It doesn't end with the build
Self tests on startup
Daily report signoff – business rules
Monitoring Example: ESP
Dev-Ops An engineer with a pager is an engineer passionate about code quality.
Summary Unit Tests Global Tests Monitoring Does my code do what I intended it to do? Is my code likely to break? Is my code actually working right now?
What we don't do (much)
No tests email
No Emma or Cobertura in build process
Ad hoc use of Emma or MoreUnit
Are coverage numbers useful?
Mostly manual at this time
If we can't run it every commit, does it have value?
Formal Code Reviews
Are humans any better than automation?
Enough better that it's worth the time cost?
Post-commit, pre-deployment SQL review
Informatal “hey, this is hairy” reviews
Pair on difficult components
Writing Comments “ We do not write a lot of comments. Since they are not executable, they tend to get out of date. Well-written tests are live specs and explain what, how and why. Get used to reading tests like you read English, and you'll be just fine. “ There are two major exceptions to the sparse comments world:
– kaChing Java Coding Style
What we don't do (and never will)
No QA department
“Throw it over the wall” leads to false sense of accomplishment
Fixing QA-found bugs seems productive
But it's actually a sign you screwed up
What we might do soon
Commit, see if tests pass
Require #rollback or #buildfix to commit
Strong social pressure to not break the build Holding up other engineers vs.
Considering moving to build queue
By-request Code Reviews
Probably depends on build queue
Dependent on switch to git?
Better staging environment
Hard for us to test data migration issues
Hard to test inter-service calls
Errors don't occur on dev boxes
Front end has it, with Selenium testing
One more thing
Check in your Eclipse project
Configure code formatting
Share your templates
Organize imports on save
Keeps your history clean
Kevin Peterson kaChing.com @kdpeterson http://eng.kaching.com