Moderate TDD
adi.roiban@gmail.com
RoPython-Cluj
2016-05-16 Cluj Napoca
background: Tiger Lily https://flic.kr/p/3QtaE
A preaching on ...
Licență Creative Commons Attribution 4.0
About Me
Generalist - Jack of all trades, master of none
developer - free software contributor
Twisted Matrix Core Dev
tiny size entrepreneur
background: Brandon Dimcheff https://flic.kr/p/dXfrM4
About You
Developer
QA / Test Specialist
Support
SysAdmin / DevOp
background: Targut https://flic.kr/p/o419bj
Context
Python/Twisted/async-io FTPS/SFTP/SCP/HTTPS
client / server / middle-ware
on-premise deployment / no internet access
Windows / Linux / Unix - 27 platforms
1 director / 3 developers / 1 qa / 1 sysadmin
0 support / 0 technical writer
0 external investors
Summary
TDD / TCD / Common Sense Programming
Moderate TDD
Tips and tricks aka practicing Moderated TDD
TDD
What is Test Driven Development / XP
Test Constrained/Backed Development
Common Sense / Worry Free Programming
test (manual or dirty) created during implementation
clean those tests, show them some love
tests will be your best friend forever
Dirty Tests
Manual click, click ... crash
Temporary code to raise (hard) exceptions
Non-automated helpers to act as external services
printf / echo / print calls
Worry Free
Focus on the current task
Free you mind off all the corner cases / exceptions
... from hundred of already implemented features
Validate the changes by running all tests
Moderate TDD
tentative
extreme
moderate
it is dangerous to go with tentative tests
and extreme is expensive
but don't be cheap an go without good tests
How can you tell?
no clear definition
Coverage
100% LOC reported coverage
100% LOC test code coverage
100% unit / integration functionality coverage
10% functional/feature end-to-end style coverage
... think selenium or other bots
no tests for the content of the end user documentation
complete tests for the MVP
1% performance tests
5% interoperability tests
100% LOC coverage is not nirvana
Test Development
see that test fails first ... it should bleed
tests for documentation build
tests broken links structure/rendering
no merge in trunk/master if the test suite fails
on all supported systems
no release without running the whole test suite
linters integrated in the test suite pyflakes/pep8
project specific / custom linters
... continuation
not one assertion per test / one functionality per test
replace printf/echo calls with an assertion
each test with its own substantial docstring
describing the targeted test scenario
all tests written by happy developers
all code and tests reviewed
by at least one happy colleague
Test Architecture
layered tests
you can skip unit tests
design / architecture as production code
test organization / tagging
PDB friendly tests
test the real deal
don't sell your soul to Mock
Test Execution
run a single test
then the whole test suite of test module
then the whole test suite
easy to run quick test compilation
new tests are in `quick` compilation by default
fail on slow tests from the `quick` compilation
Prototype / POC
no TDD
prototype / POC will not reach production
no code will reach master without a 100% rewrite
prototype / POC is not the MVP
no Leeroy Jenkins
production will hit you really bad
Production Bugs
defects will hit production
regressions are prevented
silly / simple / stupid bugs are prevented
performance problems
compatibility problems
anything which is not tested will hit you in production
Tests Recap
test code quality as production code
more test code than production code
take pride of your test code and infrastructure
take time to design them and reduce duplication
docstring and documentation for all test code
replace printf/echo calls with an assertion
PDB friendly tests
No silver bullet
competent developers to design and implement the tests
competent QA to design and validate test scenarios
competent team members to validate documentation
competent team members to validate any UI/UX
competent members to validate customers interaction
manual test of documentation changes during review
Tips and Tricks
Object generators
Double generators
Explicit side effects for tests
Test case cleanup helpers
Assertion helpers
...getting closer to the end
Avoid the Mock
ultimate lier will lie to code using it and will lie to you
prefer minimal stub/implementations
use Bunch
or use Mock with a specification
and with a context manager
use side_effect instead of return_value
create your own mock assertion helpers
sut = Mock()
sut(3, 4, key='value')
sut.asserts_called_with(3, 4, key='value')
Coverage
100% coverage for tests ... as a test
Raise AssertionErrors only in testing code
Write tests for __repr__ and everything
__str__ and __eq__ are real methods
Write a test to make sure coverage is not decreased
branch coverage / instrumental / fuzz testing
Twisted - 50%prod/50% tests - 88% code coverage
Django-CMS 50%/50x - 88% code coverage
ApplicationX - 25%prod/75% tests - 95% code coverage
Forgotten Tests
Run tests for every rev./path to be merged
Add a coverage report for the test code
Treat coverate report as a test
Treat pyflakes / pep8 / pylint as test
coverage report \
--include=you-project/tests/* \
--fail-under=100
Questions?
Suggestions
Comments
Complains
That was it
Pentru sănătatea dumneavoastră
evițati excesul
de sare, zahăr și grăsimi
adiroiban@gmail.com
slides.com / reveal.js
Moderate TDD
By adiroiban
Moderate TDD
- 1,362