The Little Shop of TDD Horrors

@giorgionatili #mobiletea 1
The Little Shop of
TDD Horrors
a story from Giorgio Natili
(the mobile & tdd dude)

Italian Accent Crash Course

A few words about me…

Lead Mobile Engineer  
(McGraw Hill Education)
@giorgionatili

Mobile Tea

www.meetup.com/pro/mobiletea

!
Setup and Teardown
Tests clarity and readability
Mocking data
Contract tests
Behaviors driven development
End to end testing
The goals of testing
What we’ll talk about

“We are going to cycle in good and bad practices
highlighting potential solutions…”
How we’ll talk about this

Everything Started with a Red Sign…

And from a bunch of notes

What’s TDD

Test Driven Development

Development life cycle
It’s all about writing enough code to
satisfy specific conditions and a
continuous refactoring

Analysis tool
Decouple requirements in independent,
negotiable, valuable, estimable, small
testable pieces of code

With TDD you are not lost anymore!

Set up and tear down

Easy setup and teardown
Understandable setups keep the test
clean and easily comprehensible for
everybody

beforeEach(function() {
provider.init(["course:read:*", "group:read:*", "settings:read:*", "settings:update:*", "activity:read:*",
"log:*:*", "node:create:*", "settings:create:*", "system:update:*",
"system:read:*", "system:delete:*", "system:create:*", "unit:create:*", "unit:read:*", "node:update:*",
"node:read:*", "node:delete:*", "splash:read:*", "path:read:*",
"master:update:*", "snapshot:read:*", "lti:grade:*", "master:read:*", "snapshot:update:*",
"history:read:*", "lti:appLaunch:*", "lti:contentItemReturn:*",
"appAction:annotationBundle.js:*", "appAction:apps:*", "appAction:annotation.js:*", "openId:read:*",
"app:read:*", "activityOutcome:activitySubmission:*",
"search:read:*", "userOrgProfile:read:*", "lti:contentItemSelectionReturn:*", "history:create:*",
"eula:read:*", "lti:editActivity:*", "userAppCategoryPref:update:*",
"platformArtifacts:read:*", "userAppCategoryPref:read:*", "userAppCategoryPref:delete:*",
"userAppCategoryPref:create:*", "appCategory:read:*",
"appActivity:update:3,4,16,48,49", "appActivity:findAddible:16,48,49", "nextbook:read:*",
"appActivity:read:*", "lti:addActivity:*",
"activityOutcome:create:*", "activityOutcome:read:*", "activityOutcome:update:*"
]);
});
Overcomplicated setup is a symptom of poor
test(s) organization!

Eventually decouple setups
Just in case you really need
complicated setups decouple them from
tests and include them in the setup…

Essentials Tests

Test the fundamentals
If you are not 100% test covered you
are not a bad person!

describe( 'AppCtrl', function() {
describe( 'isCurrentUrl', function() {
var AppCtrl, $location, $scope;
beforeEach( module( 'ngBoilerplate' ) );
beforeEach( inject( function( $controller, _$location_, $rootScope ) {
$location = _$location_;
$scope = $rootScope.$new();
AppCtrl = $controller( 'AppCtrl', { $location: $location, $scope: $scope });
}));
it( 'should pass a dummy test', inject( function() {
expect( AppCtrl ).toBeTruthy();
}));
});
});
Don’t take advantage from this!

Test, design and code quality

Big up front design is not TDD
It’s not based on cycles and it’s not
how you would design a component…

Big projects should still follow best practices…

Tests are code, treat them well
Write small, readable and decoupled
tests. Tests are part of your code base,
don’t write garbage code!

Treat your tests as a welcome guests

Refactor on green
Don’t refactor code or tests until the
tests are not green…

Readability

Readable
Never write tests that nobody wants or
is able to read, you’ll stop to read them
too

@implementation CardTests
- (void)testFlag {
[self login];
NSManagedObjectContext *context = [CoreDataManager sharedManager].operationContext;
Section *testSection = [Section sectionForUpsertWithSectionId:@(1) forUserId:self.testUserId
inContext:context]; 
// Completed activities should not show a due soon indicator even when due soon.
Activity *activityNotStarted = [Activity activityForUpsertWithActivityId:@(2)
forSection:testSection inContext:context];
activityNotStarted.progressStatus = ActivityProgressStatusNotYetStarted;
activityNotStarted.due = [NSDate distantFuture];
Card *cardForActivityNotStarted = [Card cardForUpsertWithActivityDue:activityNotStarted];
XCTAssertEqualObjects(SCLocStr(@"ACTIVITY_FLAG_NOT_STARTED"),
cardForActivityNotStarted.flag); 
// Repeated for 6 different scenarios… 
@end
Boring and not useful

Do you like to read like this?

Time box writing tests
You should be driven away from
writing long tests and large amounts of
code to satisfy them

Privacy

Respect the privacy
Don’t expose methods just because you
have to test it: Well-designed public
methods should use them in such a way
they don’t need be directly tested

Reflection + methods swizzling
Don’t expose private methods -even
temporarily - you are terrorizing your
own design

Repetitive Cases

Automate repetitive cases
Use generative tests framework to
mock repetitive cases in your tests

describe('pow', function() {
it('works for simple cases', function() {
assert.equal(pow(2, 1), 2);
});
});
From this mess…

forAll([gentest.types.int, gentest.types.int],
'pow works like builtin',
function(base, exponent) {
var builtinPow = Math.pow(base, exponent);
var ourPow = pow(base, exponent);
return (builtinPow === ourPow ||
relativeErrorWithin(0.000000001, builtinPow, ourPow));
});
To a better code!

You feel better!

Clarity

Clarity
The clarity of expectations and
assertions is the key for effective TDD

Naming
Don’t be worried about the length of the
names, a right name is the key to be
understood by the others

Poor descriptions
Tests descriptions are one of the best
sources of documentation, never ignore
the importance of providing a good
description

Respect laziness
Never force a stakeholder to read the
code contained in a test to understand
its purpose

Arrange, Act, Assert (AAA)
Separate what is going to be tested
from the setups and keep the
verification steps clearly identified

Conditional Behaviors

Avoid conditional behaviors
If you start to add conditionals to
determine if your code is executed by
the tests suites, it means that you are in
danger

Ambiguous behaviors are dangerous!

“TDD is not about
preventing bugs, it’s
about proving the
exactness of
behaviors”

There are unpredictable conditions!

but you can still mitigate them…

Network Responses and API

Network Responses
Applications rely on external data
sources, it’s important to have clear
expectations about external APIs
responses

Performance
Tests are code: Never ignore
performance issues and bottlenecks

Mock Data
Mock only the data you are testing. A
mock should be small and
understandable

Contract Tests
Create tests in a separate environment
that checks the sanity of the external
API you rely on

'use strict';
var supertest = require('supertest-as-promised');
var request = supertest('https://ngcourse.herokuapp.com');
var assert = require('chai').assert;
describe('Backend API', function() {
it ('should return the list of users', function() {
return request.get('/api/v1/users')
.expect(200);
});
});
Contract Tests in Practice

Behaviors

Behaviors
Focus on testing software behaviors
rather then single units of code

Organize behaviors
Group tests and behaviors that are tied
to specific, testable functionality of
your software

Connect behaviors
Create a connection between behaviors
and scenarios with a format like
given/then/when

Divide tests logically
Never violate the Single Responsibility
Principle neither when writing tests,
keep the ordered and in a good shape
is the key to get the more value from
them…

Measure complexity
If you are not able to organize your
tests in such a way it means that you
are dealing with confusing (poor!)
requirements

Scenarios -> Use Cases -> Behaviors
This connection is the key to defining
tests that clearly describe a feature and
its acceptance criteria

End 2 End Testing

Test for pixels
Don’t use e2e tests for testing layout
implementations, automate (eventually)
screenshots and then examine them

Counting elements
Don’t use e2e testing to count UI
elements, use them to describe how the
UI *should change* with a specific
behavior

Writing E2E tests
Never wait too much, start to write end
user tests as soon as the requirements
are ready, the lack of automation can
bring to not reliable outputs

The Goals of Testing

Do you ever asked to yourself?

Profitable
Tests should always support the end
goal of making profit from a software

Maintainability
Tests are a means to increase
maintainability of a software

Common understanding
Don’t separate developers and testers!
Keeping them together allows you to
have testers that understand the app
internals

Interchangeability
Having pairing working alternatively on
code and tests is the key to having
different perspectives and to improve
interchangeability in your team

Conclusions

Preconditions
If you cannot define preconditions you
cannot write tests of good quality,
potentially there is a big
misunderstanding about requirements

Quality
The quality of a test can be highly
opinionated; let’s find a metric that is
valuable for your organization

Validate
Write tests to validate the
understanding of the behaviors a
software should implement not to
validate the code

Estimate
Writing tests take time. Count it in
your estimates but keep always in mind
the time that is then saved during the
maintaining phase

Questions

THANK YOU

The Little Shop of TDD Horrors

Recommended

Recommended

More Related Content

Similar to The Little Shop of TDD Horrors

Similar to The Little Shop of TDD Horrors (20)

More from Giorgio Natili

More from Giorgio Natili (15)

Recently uploaded

Recently uploaded (20)

The Little Shop of TDD Horrors