One of the cornerstones in Agile development is fast feedback. For engineering, "fast" means "instantly" or "in 5 minutes", not "tomorrow" or "this week". Your engineering practices should ensure that you can answer yes to most of the following questions: - Do we get all test results in less than 5 minutes after a commit? - Is our code coverage more than 75% for both front-end and back-end? - Can we start exploratory testing in less than 15 minutes after a commit? - Do all our tests pass more than 90% of our commits? This talk will give you practical advice on how to get to "yes, we get fast feedback".

1. Put fast
back in fast feedback
Lars Thorup
ZeaLake Software Consulting
October, 2013

2. Who is Lars Thorup?
●
Software developer/architect
●
●
●
Coach
●
●
●
C#, JavaScript and C++
Test Driven Development
Agile engineering practices
Assessing software projects and
companies
@larsthorup

3. Fast feedback is important
●
Cost of change
●
●
●
Lower risk
●
●
●
Defects found quickly
...are cheap to fix
Systems delivered frequently
...are easy to adapt to evolving
requirements
Fast feedback will make you
more productive

4. How are you doing?
Unit test run time
seconds
few minutes
> 10 minutes
Unit test coverage
<25%
<50%
>50%
minutes
> 30 minutes
hours
Commits per dev per day
10
1
<1
Releases per week
50
1
<1
trend lines
status
no
Integration test run time
Visible metrics of this

5. Real life stories
●
Slow feedback
●
●
●
●
●
Large insurance system
provider
Nightly builds, Selenium
tests only
4 hours, usually some
failures
Weekly commits
Slow feedback
●
●
●
Large online store
Huge number of Selenium
tests
12 hours, usually >25%
failures
●
Fast feedback
●
●
●
●
●
Large interactive meetings
Hourly commits
75% unit test coverage
<5 minute to build, test and
release
Fast feedback
●
●
●
●
●
Same large online store
Daily commits
75% unit test coverage
<2 minutes to test
1/10th QA issues

6. Feedback goals
●
Slow feedback, if you:
●
●
●
●
Get <10% of your code
coverage through unit tests
Manual or nightly builds
Weekly commits
Merge feature branches on
a monthly basis
●
Fast feedback: if you
●
●
●
●
●
●
Get >75% of your code
coverage through unit tests
Release on every commit
Commit many times every
day
Avoid branching in the
version control system
...instead do branch by
abstraction in the code
http://martinfowler.com/bliki/
BranchByAbstraction.html

7. Show - don't tell
●
C# unit testing
●
●
JavaScript unit testing
●
●
nant unittest / TestDriven.NET
grunt test:unit / all.test.html
TeamCity
●
●
Fast build, artifacts
Code coverage

8. Techniques, tools and metrics

9. Elephant carpaccio
●
How do you build an elephant - one slice at a time
●
Smaller slices give faster feedback
Start
Release date
Time

10. Mocks and stubs
●
When testing an object X, that depends on an object Y
●
replace the real Y with a fake Y
NotifierTest
IEmailSvc
EmailSvcStub
EmailSvc
Notifier

11. Test-Driven Development
●
Every TDD microstep gives you fast feedback
Think, talk
Idea
Test
Failing
test
Good
design
Refactor
Succeeding
test

12. Enforce "fast"
●
Break the build when it's not fast

13. Tools
●
JavaScript
●
●
●
●
●
●
Jasmine
QUnit
SinonJS
GruntJS
Karma
Istanbul
●
Java
●
●
●
●
C++
●
●
●
.NET
●
●
●
●
NUnit
NSubstitute
NAnt
NCover
●
●
JUnit
Mockito
Cobertura
Google Test
Google Mock
Mockito++
Continuous Integration
●
●
Jenkins
TeamCity

14. Metric - commit frequency

15. Metric - unit test run time

16. Metric - unit test coverage

17. Metric - release frequency

18. It's not hard - now go do it!
●
This is hard
●
●
●
●
●
●
●
●
●
●
SQL query efficiency
Cache invalidation
Scalability
Pixel perfect rendering
Cross-browser compatibility
Indexing strategies
Security
Real time media streaming
60fps gaming with HTML5
... and robust Selenium tests!
●
This is not hard
●
●
●
●
●
Unit testing
Dependency injection
Automated build and test
Continuous Integration
Fast feedback will make
you more productive
●
... and more happy