Giorgio Natili - The Little Shop of TDD Horrors

@giorgionatili #mobiletea 1

The Little Shop of TDD Horrors

a story from Giorgio Natili (the mobile & tdd dude)


let licensing = CC + WTFPL


A few words about me…


Lead Mobile Engineer (McGraw Hill Education)

@giorgionatili


Mobile Tea


www.meetup.com/pro/mobiletea

http://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


Avoid the “Red” in ProcessTest-Driven Development is not the one true programming methodology, testing is a tool for helping you!!!


What’s TDD


Test Driven Development


Development life cycleIt’s all about writing enough code to satisfy specific conditions and a continuous refactoring of the code


Analysis toolDecouple 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 teardownUnderstandable 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! Code coverage is just about the quantity, not the quality!


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…


Iterative Testing

Writing all the tests first is a mistake because you cannot have a complete understanding of a feature from a user story


Existing Code

Don’t write tests unless you have to modify the original code and change the behavior


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


Edge Cases


Edge Cases and Code

Don’t start with edge cases (empty string, null parameter) or error cases, this has to happen in code!


Tests the Behavior

A test must validate a behavior, not an input otherwise they don’t deliver any business value, nor do validate the product owner’s assumptions


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); assert.equal(pow(2, 2), 4); assert.equal(pow(2, 5), 32); assert.equal(pow(2, 8), 256); assert.equal(pow(3, 2), 9); assert.equal(pow(10, 4), 10000); assert.equal(pow(1, 99), 1); }); });

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 them 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 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 the 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


Special thanks to:

• Codemotion Italia • codeinvaders.net

http://codeinvaders.net


THANK YOU

Technology

Giorgio Natili - The Little Shop of TDD Horrors