Moderate TDD

adi.roiban@gmail.com

RoPython-Cluj

2016-05-16 Cluj Napoca 

background: Tiger Lily  https://flic.kr/p/3QtaE

A preaching on ...

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

https://travis-ci.org/chevah/chevah-keycert

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,275