Date post: | 22-Jan-2018 |
Category: |
Technology |
Upload: | codemotion |
View: | 263 times |
Download: | 0 times |
@giorgionatili #mobiletea 1
The Little Shop of TDD Horrors
a story from Giorgio Natili (the mobile & tdd dude)
@giorgionatili #mobiletea 2
let licensing = CC + WTFPL
@giorgionatili #mobiletea 3
A few words about me…
@giorgionatili #mobiletea 4
Lead Mobile Engineer (McGraw Hill Education)
@giorgionatili
@giorgionatili #mobiletea 5
Mobile Tea
@giorgionatili #mobiletea 7
!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
@giorgionatili #mobiletea 9
Everything Started with a Red Sign…
@giorgionatili #mobiletea 10
And from a bunch of notes
@giorgionatili #mobiletea 11
Avoid the “Red” in ProcessTest-Driven Development is not the one true programming methodology, testing is a tool for helping you!!!
@giorgionatili #mobiletea 12
What’s TDD
@giorgionatili #mobiletea 13
Test Driven Development
@giorgionatili #mobiletea 14
Development life cycleIt’s all about writing enough code to satisfy specific conditions and a continuous refactoring of the code
@giorgionatili #mobiletea 15
Analysis toolDecouple requirements in independent, negotiable, valuable, estimable, small testable pieces of code
@giorgionatili #mobiletea 16
With TDD you are not lost anymore!
@giorgionatili #mobiletea 17
Set up and tear down
@giorgionatili #mobiletea 18
Easy setup and teardownUnderstandable setups keep the test clean and easily comprehensible for everybody
@giorgionatili #mobiletea 19
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!
@giorgionatili #mobiletea 20
Eventually decouple setups
Just in case you really need complicated setups decouple them from tests and include them in the setup…
@giorgionatili #mobiletea 21
Essentials Tests
@giorgionatili #mobiletea 22
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!
@giorgionatili #mobiletea 23
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!
@giorgionatili #mobiletea 24
Test, design and code quality
@giorgionatili #mobiletea 25
Big up front design is not TDD
It’s not based on cycles and it’s not how you would design a component…
@giorgionatili #mobiletea 26
Big projects should still follow best practices…
@giorgionatili #mobiletea 27
Tests are code, treat them well
Write small, readable and decoupled tests. Tests are part of your code base, don’t write garbage code!
@giorgionatili #mobiletea 28
Treat your tests as a welcome guests
@giorgionatili #mobiletea 29
Refactor on green
Don’t refactor code or tests until the tests are not green…
@giorgionatili #mobiletea 30
Iterative Testing
Writing all the tests first is a mistake because you cannot have a complete understanding of a feature from a user story
@giorgionatili #mobiletea 31
Existing Code
Don’t write tests unless you have to modify the original code and change the behavior
@giorgionatili #mobiletea 32
Readability
@giorgionatili #mobiletea 33
Readable
Never write tests that nobody wants or is able to read, you’ll stop to read them too
@giorgionatili #mobiletea 34
@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
@giorgionatili #mobiletea 35
Do you like to read like this?
@giorgionatili #mobiletea 36
Time box writing tests
You should be driven away from writing long tests and large amounts of code to satisfy them
@giorgionatili #mobiletea 37
Privacy
@giorgionatili #mobiletea 38
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
@giorgionatili #mobiletea 39
Reflection + methods swizzling
Don’t expose private methods - even temporarily - you are terrorizing your own design
@giorgionatili #mobiletea 40
Edge Cases
@giorgionatili #mobiletea 41
Edge Cases and Code
Don’t start with edge cases (empty string, null parameter) or error cases, this has to happen in code!
@giorgionatili #mobiletea 42
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
@giorgionatili #mobiletea 43
Repetitive Cases
@giorgionatili #mobiletea 44
Automate repetitive cases
Use generative tests framework to mock repetitive cases in your tests
@giorgionatili #mobiletea 45
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…
@giorgionatili #mobiletea 46
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!
@giorgionatili #mobiletea 47
You feel better!
@giorgionatili #mobiletea 48
Clarity
@giorgionatili #mobiletea 49
Clarity
The clarity of expectations and assertions is the key for effective TDD
@giorgionatili #mobiletea 50
Naming
Don’t be worried about the length of the names, a right name is the key to be understood by the others
@giorgionatili #mobiletea 51
Poor descriptions
Tests descriptions are one of the best sources of documentation, never ignore the importance of providing a good description
@giorgionatili #mobiletea 52
Respect laziness
Never force a stakeholder to read the code contained in a test to understand its purpose
@giorgionatili #mobiletea 53
Arrange, Act, Assert (AAA)
Separate what is going to be tested from the setups and keep the verification steps clearly identified
@giorgionatili #mobiletea 54
Conditional Behaviors
@giorgionatili #mobiletea 55
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
@giorgionatili #mobiletea 56
Ambiguous behaviors are dangerous!
@giorgionatili #mobiletea 57
“TDD is not about preventing bugs, it’s about proving the
exactness of behaviors”
@giorgionatili #mobiletea 58
There are unpredictable conditions!
@giorgionatili #mobiletea 59
but you can still mitigate them…
@giorgionatili #mobiletea 60
Network Responses and API
@giorgionatili #mobiletea 61
Network Responses
Applications rely on external data sources, it’s important to have clear expectations about external APIs responses
@giorgionatili #mobiletea 62
Performance
Tests are code: Never ignore performance issues and bottlenecks
@giorgionatili #mobiletea 63
Mock Data
Mock only the data you are testing. A mock should be small and understandable
@giorgionatili #mobiletea 64
Contract Tests
Create tests in a separate environment that checks the sanity of the external API you rely on
@giorgionatili #mobiletea 65
'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
@giorgionatili #mobiletea 66
Behaviors
@giorgionatili #mobiletea 67
Behaviors
Focus on testing software behaviors rather then single units of code
@giorgionatili #mobiletea 68
Organize behaviors
Group tests and behaviors that are tied to specific, testable functionality of your software
@giorgionatili #mobiletea 69
Connect behaviors
Create a connection between behaviors and scenarios with a format like given/then/when
@giorgionatili #mobiletea 70
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…
@giorgionatili #mobiletea 71
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
@giorgionatili #mobiletea 72
Scenarios -> Use Cases -> Behaviors
This connection is the key to defining tests that clearly describe a feature and its acceptance criteria
@giorgionatili #mobiletea 73
End 2 End Testing
@giorgionatili #mobiletea 74
Test for pixels
Don’t use e2e tests for testing layout implementations, automate (eventually) screenshots and then examine them
@giorgionatili #mobiletea 75
Counting elements
Don’t use e2e testing to count UI elements, use them to describe how the UI *should change* with a specific behavior
@giorgionatili #mobiletea 76
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
@giorgionatili #mobiletea 77
The Goals of Testing
@giorgionatili #mobiletea 78
Do you ever asked to yourself?
@giorgionatili #mobiletea 79
Profitable
Tests should always support the end goal of making profit from a software
@giorgionatili #mobiletea 80
Maintainability
Tests are a means to increase the maintainability of a software
@giorgionatili #mobiletea 81
Common understanding
Don’t separate developers and testers! Keeping them together allows you to have testers that understand the app internals
@giorgionatili #mobiletea 82
Interchangeability
Having pairing working alternatively on code and tests is the key to having different perspectives and to improve interchangeability in your team
@giorgionatili #mobiletea 83
Conclusions
@giorgionatili #mobiletea 84
Preconditions
If you cannot define preconditions you cannot write tests of good quality, potentially there is a big misunderstanding about requirements
@giorgionatili #mobiletea 85
Quality
The quality of a test can be highly opinionated; let’s find a metric that is valuable for your organization
@giorgionatili #mobiletea 86
Validate
Write tests to validate the understanding of the behaviors a software should implement not to validate the code
@giorgionatili #mobiletea 87
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
@giorgionatili #mobiletea 88
Questions
@giorgionatili #mobiletea 89
Special thanks to:
• Codemotion Italia • codeinvaders.net
@giorgionatili #mobiletea 90
THANK YOU