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 speciﬁc
conditions and a continuous refactoring of the code

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

Reﬂection + 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 veriﬁcation steps clearly identiﬁed

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 speciﬁc,
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
(and poor!) requirements

Scenarios -> Use Cases -> Behaviors
This connection is the key to deﬁning 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
speciﬁc 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?

Proﬁtable
Tests should always support the end goal of making
proﬁt 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 deﬁne 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
ﬁnd 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

Special thanks to:
•Shawn Pucknell
•Jacqueline Poole
•Rafael Fernandes
• Jonathan Barton

THANK YOU

The Little Shop of TDD Horrors

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (18)

Similar to The Little Shop of TDD Horrors

Similar to The Little Shop of TDD Horrors (20)

More from FITC

More from FITC (20)

Recently uploaded

Recently uploaded (20)

The Little Shop of TDD Horrors