Tweet
Tweet

Slide 1

Slide 1 text

Dave Farley http://www.davefarley.net @davefarley77 http://www.continuous-delivery.co.uk Acceptance Testing for Continuous Delivery

Slide 2

Slide 2 text

The Role of Acceptance Testing Local Dev. Env. Source Repository

Slide 3

Slide 3 text

The Role of Acceptance Testing Artifact Repository Local Dev. Env. Deployment Pipeline Commit Production Env. Deployment App. Commit Acceptance Manual Perf1 Perf2 Staged Production Source Repository Acceptance Component Performance System Performance Staging Env. Deployment App. Manual Test Env. Deployment App.

Slide 4

Slide 4 text

The Role of Acceptance Testing Artifact Repository Local Dev. Env. Deployment Pipeline Commit Production Env. Deployment App. Commit Acceptance Manual Perf1 Perf2 Staged Production Source Repository Acceptance Component Performance System Performance Staging Env. Deployment App. Manual Test Env. Deployment App. Staging Env. Deployment App. Manual Test Env. Deployment App. Component Performance System Performance Acceptance

Slide 5

Slide 5 text

The Role of Acceptance Testing Artifact Repository Local Dev. Env. Deployment Pipeline Commit Production Env. Deployment App. Commit Acceptance Manual Perf1 Perf2 Staged Production Source Repository Acceptance Component Performance System Performance Staging Env. Deployment App. Manual Test Env. Deployment App. Staging Env. Deployment App. Manual Test Env. Deployment App. Component Performance System Performance Acceptance

Slide 6

Slide 6 text

What is Acceptance Testing? Asserts that the code does what the users want.

Slide 7

Slide 7 text

What is Acceptance Testing? An automated “definition of done”

Slide 8

Slide 8 text

What is Acceptance Testing? Asserts that the code works in a “production-like” test environment.

Slide 9

Slide 9 text

What is Acceptance Testing? A test of the deployment and configuration of a whole system.

Slide 10

Slide 10 text

What is Acceptance Testing? Provides timely feedback on stories - closes a feedback loop.

Slide 11

Slide 11 text

What is Acceptance Testing? Acceptance Testing, ATDD, BDD, Specification by Example, Executable Specifications.

Slide 12

Slide 12 text

What is Acceptance Testing? A Good Acceptance Test is: An Executable Specification of the Behaviour of the System

Slide 13

Slide 13 text

What is Acceptance Testing? Unit Test Code Idea Executable spec. Build Release

Slide 14

Slide 14 text

What is Acceptance Testing? Unit Test Code Idea Executable spec. Build Release

Slide 15

Slide 15 text

What is Acceptance Testing? Unit Test Code Idea Executable spec. Build Release

Slide 16

Slide 16 text

So What’s So Hard? • Tests break when the SUT changes (Particularly UI) • Tests are complex to develop • This is a problem of design, the tests are too tightly-coupled to the SUT! • The history is littered with poor implementations: • UI Record-and-playback Systems • Record-and-playback of production data • Dumps of production data to test systems • Nasty automated testing products.

Slide 17

Slide 17 text

So What’s So Hard? • Tests break when the SUT changes (Particularly UI) • Tests are complex to develop • This is a problem of design, the tests are too tightly-coupled to the SUT! • The history is littered with poor implementations: • UI Record-and-playback Systems • Record-and-playback of production data • Dumps of production data to test systems • Nasty automated testing products. Anti-Pattern! Anti-Pattern! Anti-Pattern! Anti-Pattern!

Slide 18

Slide 18 text

Who Owns the Tests? • Anyone can write a test • Developers are the people that will break tests • Therefore Developers own the responsibility to keep them working • Separate Testing/QA team owning automated tests

Slide 19

Slide 19 text

Who Owns the Tests? • Anyone can write a test • Developers are the people that will break tests • Therefore Developers own the responsibility to keep them working • Separate Testing/QA team owning automated tests Anti-Pattern!

Slide 20

Slide 20 text

Who Owns the Tests? Developers Own Acceptance Tests!

Slide 21

Slide 21 text

Properties of Good Acceptance Tests • “What” not “How” • Isolated from other tests • Repeatable • Uses the language of the problem domain • Tests ANY change • Efficient

Slide 22

Slide 22 text

Properties of Good Acceptance Tests • “What” not “How” • Isolated from other tests • Repeatable • Uses the language of the problem domain • Tests ANY change • Efficient

Slide 23

Slide 23 text

Public API FIX API Trade Reporting Gateway … “What” not “How” API Traders Clearing Destination Other external end-points Market Makers UI Traders

Slide 24

Slide 24 text

Public API FIX API Trade Reporting Gateway … “What” not “How” Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case

Slide 25

Slide 25 text

Public API FIX API Trade Reporting Gateway … FIX API “What” not “How” Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case

Slide 26

Slide 26 text

Public API FIX API Trade Reporting Gateway … “What” not “How” API Traders Clearing Destination Other external end-points Market Makers UI Traders Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case

Slide 27

Slide 27 text

Public API FIX API Trade Reporting Gateway … “What” not “How” FIX API Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case API External Stubs FIX-API UI FIX-API FIX-API Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case

Slide 28

Slide 28 text

Public API FIX API Trade Reporting Gateway … “What” not “How” FIX API Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case API External Stubs FIX-API UI FIX-API

Slide 29

Slide 29 text

Public API FIX API Trade Reporting Gateway … “What” not “How” Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case Test Case API External Stubs FIX-API UI FIX-API

Slide 30

Slide 30 text

Public API FIX API Trade Reporting Gateway … “What” not “How” API External Stubs FIX-API UI FIX-API Test infrastructure common to all acceptance tests

Slide 31

Slide 31 text

“What” not “How” - Separate Deployment from Testing • Every Test should control its start conditions, and so should start and init the app. • Acceptance Test deployment should be a rehearsal for Production Release • This separation of concerns provides an opportunity for optimisation • Parallel tests in a shared environment • Lower test start-up overhead

Slide 32

Slide 32 text

“What” not “How” - Separate Deployment from Testing • Every Test should control its start conditions, and so should start and init the app. • Acceptance Test deployment should be a rehearsal for Production Release • This separation of concerns provides an opportunity for optimisation • Parallel tests in a shared environment • Lower test start-up overhead Anti-Pattern!

Slide 33

Slide 33 text

Properties of Good Acceptance Tests • “What” not “How” • Isolated from other tests • Repeatable • Uses the language of the problem domain • Tests ANY change • Efficient

Slide 34

Slide 34 text

Properties of Good Acceptance Tests • “What” not “How” • Isolated from other tests • Repeatable • Uses the language of the problem domain • Tests ANY change • Efficient

Slide 35

Slide 35 text

Test Isolation • Any form of testing is about evaluating something in controlled circumstances • Isolation works on multiple levels • Isolating the System under test • Isolating test cases from each other • Isolating test cases from themselves (temporal isolation) • Isolation is a vital part of your Test Strategy

Slide 36

Slide 36 text

Test Isolation - Isolating the System Under Test

Slide 37

Slide 37 text

Test Isolation - Isolating the System Under Test External System ‘A’ External System ‘C’ System Under Test ‘B’

Slide 38

Slide 38 text

Test Isolation - Isolating the System Under Test External System ‘A’ External System ‘C’ System Under Test ‘B’

Slide 39

Slide 39 text

Test Isolation - Isolating the System Under Test External System ‘A’ External System ‘C’ System Under Test ‘B’

Slide 40

Slide 40 text

Test Isolation - Isolating the System Under Test External System ‘A’ External System ‘C’ System Under Test ‘B’ ?

Slide 41

Slide 41 text

Test Isolation - Isolating the System Under Test External System ‘A’ External System ‘C’ System Under Test ‘B’ Anti-Pattern!

Slide 42

Slide 42 text

Test Isolation - Isolating the System Under Test System Under Test ‘B’ Test Cases Verifiable Output

Slide 43

Slide 43 text

Test Isolation - Validating The Interfaces

Slide 44

Slide 44 text

Test Isolation - Validating The Interfaces External System ‘A’ External System ‘C’ System Under Test ‘B’

Slide 45

Slide 45 text

Test Isolation - Validating The Interfaces External System ‘A’ External System ‘C’ System Under Test ‘B’

Slide 46

Slide 46 text

Test Isolation - Validating The Interfaces External System ‘A’ External System ‘C’ Test Cases Verifiable Output System Under Test ‘B’ Test Cases Verifiable Output Test Cases Verifiable Output

Slide 47

Slide 47 text

Test Isolation - Validating The Interfaces External System ‘A’ External System ‘C’ Test Cases Verifiable Output System Under Test ‘B’ Test Cases Verifiable Output Test Cases Verifiable Output

Slide 48

Slide 48 text

Test Isolation - Isolating Test Cases • Assuming multi-user systems… • Tests should be efficient - We want to run LOTS! • What we really want is to deploy once, and run LOTS of tests • So we must avoid ANY dependencies between tests… • Use natural functional isolation e.g. • If testing Amazon, create a new account and a new book/product for every test-case • If testing eBay create a new account and a new auction for every test-case • If testing GitHub, create a new account and a new repository for every test-case • …

Slide 49

Slide 49 text

• We want repeatable results • If I run my test-case twice it should work both times Test Isolation - Temporal Isolation

Slide 50

Slide 50 text

• We want repeatable results • If I run my test-case twice it should work both times Test Isolation - Temporal Isolation def test_should_place_an_order(self): self.store.createBook(“Continuous Delivery”); order = self.store.placeOrder(book=“Continuous Delivery") self.store.assertOrderPlaced(order)

Slide 51

Slide 51 text

• We want repeatable results • If I run my test-case twice it should work both times Test Isolation - Temporal Isolation def test_should_place_an_order(self): self.store.createBook(“Continuous Delivery”); order = self.store.placeOrder(book=“Continuous Delivery") self.store.assertOrderPlaced(order)

Slide 52

Slide 52 text

• We want repeatable results • If I run my test-case twice it should work both times Test Isolation - Temporal Isolation def test_should_place_an_order(self): self.store.createBook(“Continuous Delivery”); order = self.store.placeOrder(book=“Continuous Delivery") self.store.assertOrderPlaced(order)

Slide 53

Slide 53 text

• We want repeatable results • If I run my test-case twice it should work both times Test Isolation - Temporal Isolation def test_should_place_an_order(self): self.store.createBook(“Continuous Delivery”); order = self.store.placeOrder(book=“Continuous Delivery") self.store.assertOrderPlaced(order) Continuous Delivery

Slide 54

Slide 54 text

• We want repeatable results • If I run my test-case twice it should work both times Test Isolation - Temporal Isolation def test_should_place_an_order(self): self.store.createBook(“Continuous Delivery”); order = self.store.placeOrder(book=“Continuous Delivery") self.store.assertOrderPlaced(order) Continuous Delivery

Slide 55

Slide 55 text

• We want repeatable results • If I run my test-case twice it should work both times Test Isolation - Temporal Isolation def test_should_place_an_order(self): self.store.createBook(“Continuous Delivery”); order = self.store.placeOrder(book=“Continuous Delivery") self.store.assertOrderPlaced(order) Continuous Delivery1234

Slide 56

Slide 56 text

• We want repeatable results • If I run my test-case twice it should work both times Test Isolation - Temporal Isolation def test_should_place_an_order(self): self.store.createBook(“Continuous Delivery”); order = self.store.placeOrder(book=“Continuous Delivery") self.store.assertOrderPlaced(order) Continuous Delivery1234 Continuous Delivery6789

Slide 57

Slide 57 text

• We want repeatable results • If I run my test-case twice it should work both times Test Isolation - Temporal Isolation def test_should_place_an_order(self): self.store.createBook(“Continuous Delivery”); order = self.store.placeOrder(book=“Continuous Delivery") self.store.assertOrderPlaced(order) Continuous Delivery1234 Continuous Delivery6789 • Alias your functional isolation entities • In your test case create account ‘Dave’ in reality, in the test infrastructure, ask the application to create account ‘Dave2938472398472’ and alias it to ‘Dave’ in your test infrastructure.

Slide 58

Slide 58 text

Properties of Good Acceptance Tests • “What” not “How” • Isolated from other tests • Repeatable • Uses the language of the problem domain • Tests ANY change • Efficient

Slide 59

Slide 59 text

Properties of Good Acceptance Tests • “What” not “How” • Isolated from other tests • Repeatable • Uses the language of the problem domain • Tests ANY change • Efficient

Slide 60

Slide 60 text

Repeatability - Test Doubles External System

Slide 61

Slide 61 text

Repeatability - Test Doubles External System Local Interface to External System

Slide 62

Slide 62 text

Repeatability - Test Doubles External System Local Interface to External System Communications to External System

Slide 63

Slide 63 text

Repeatability - Test Doubles External System Local Interface to External System Communications to External System TestStub Simulating External System Local Interface to External System

Slide 64

Slide 64 text

Repeatability - Test Doubles External System Local Interface to External System Communications to External System TestStub Simulating External System Local Interface to External System Production Test Environm ent kjhaskjhdkjhkjh askjhl lkjasl dkjas lkajl ajsd lkjalskjlakjsdlkajsld j lkajsdlkajsldkj lkjlakjsldkjlka laskj ljl akjl kajsldijupoqwiuepoq dlkjl iu lkajsodiuqpwouoi la ]laksjdiuqoiwuoijds oijasodiaosidjuoiasud kjhaskjhdkjhkjh askjhl lkjasl dkjas lkajl ajsd lkjalskjlakjsdlkajsld j lkajsdlkajsldkj lkjlakjsldkjlka laskj ljl akjl kajsldijupoqwiuepoq dlkjl iu lkajsodiuqpwouoi la ]laksjdiuqoiwuoijds oijasodiaosidjuoiasud Configuration

Slide 65

Slide 65 text

Test Doubles As Part of Test Infrastructure TestStub Simulating External System Local Interface to External System

Slide 66

Slide 66 text

Test Doubles As Part of Test Infrastructure TestStub Simulating External System Local Interface to External System

Slide 67

Slide 67 text

Test Doubles As Part of Test Infrastructure TestStub Simulating External System Local Interface to External System Public Interface

Slide 68

Slide 68 text

Test Doubles As Part of Test Infrastructure TestStub Simulating External System Local Interface to External System Public Interface

Slide 69

Slide 69 text

Test Doubles As Part of Test Infrastructure TestStub Simulating External System Local Interface to External System Test Infrastructure Test Case Test Case Test Case Test Case Test Infrastructure Back-Channel Public Interface System Under Test

Slide 70

Slide 70 text

Properties of Good Acceptance Tests • “What” not “How” • Isolated from other tests • Repeatable • Uses the language of the problem domain • Tests ANY change • Efficient

Slide 71

Slide 71 text

Properties of Good Acceptance Tests • “What” not “How” • Isolated from other tests • Repeatable • Uses the language of the problem domain • Tests ANY change • Efficient

Slide 72

Slide 72 text

Language of the Problem Domain - DSL • A Simple ‘DSL’ Solves many of our problems • Ease of TestCase creation • Readability • Ease of Maintenance • Separation of “What” from “How” • Test Isolation • The Chance to abstract complex set-up and scenarios • …

Slide 73

Slide 73 text

Language of the Problem Domain - DSL @Test public void shouldSupportPlacingValidBuyAndSellLimitOrders() { trading.selectDealTicket("instrument"); trading.dealTicket.placeOrder("type: limit", ”bid: 4@10”); trading.dealTicket.checkFeedbackMessage("You have successfully sent a limit order to buy 4.00 contracts at 10.0"); trading.dealTicket.dismissFeedbackMessage(); trading.dealTicket.placeOrder("type: limit", ”ask: 4@9”); trading.dealTicket.checkFeedbackMessage("You have successfully sent a limit order to sell 4.00 contracts at 9.0"); }

Slide 74

Slide 74 text

Language of the Problem Domain - DSL @Test public void shouldSupportPlacingValidBuyAndSellLimitOrders() { trading.selectDealTicket("instrument"); trading.dealTicket.placeOrder("type: limit", ”bid: 4@10”); trading.dealTicket.checkFeedbackMessage("You have successfully sent a limit order to buy 4.00 contracts at 10.0"); trading.dealTicket.dismissFeedbackMessage(); trading.dealTicket.placeOrder("type: limit", ”ask: 4@9”); trading.dealTicket.checkFeedbackMessage("You have successfully sent a limit order to sell 4.00 contracts at 9.0"); } @Test public void shouldSuccessfullyPlaceAnImmediateOrCancelBuyMarketOrder() { fixAPIMarketMaker.placeMassOrder("instrument", "ask: 11@52", "ask: 10@51", "ask: 10@50", "bid: 10@49"); fixAPI.placeOrder("instrument", "side: buy", "quantity: 4", "goodUntil: Immediate", "allowUnmatched: true"); fixAPI.waitForExecutionReport("executionType: Fill", "orderStatus: Filled", "side: buy", "quantity: 4", "matched: 4", "remaining: 0", "executionPrice: 50", "executionQuantity: 4"); }

Slide 75

Slide 75 text

Language of the Problem Domain - DSL @Test public void shouldSupportPlacingValidBuyAndSellLimitOrders() { trading.selectDealTicket("instrument"); trading.dealTicket.placeOrder("type: limit", ”bid: 4@10”); trading.dealTicket.checkFeedbackMessage("You have successfully sent a limit order to buy 4.00 contracts at 10.0"); trading.dealTicket.dismissFeedbackMessage(); trading.dealTicket.placeOrder("type: limit", ”ask: 4@9”); trading.dealTicket.checkFeedbackMessage("You have successfully sent a limit order to sell 4.00 contracts at 9.0"); } @Test public void shouldSuccessfullyPlaceAnImmediateOrCancelBuyMarketOrder() { fixAPIMarketMaker.placeMassOrder("instrument", "ask: 11@52", "ask: 10@51", "ask: 10@50", "bid: 10@49"); fixAPI.placeOrder("instrument", "side: buy", "quantity: 4", "goodUntil: Immediate", "allowUnmatched: true"); fixAPI.waitForExecutionReport("executionType: Fill", "orderStatus: Filled", "side: buy", "quantity: 4", "matched: 4", "remaining: 0", "executionPrice: 50", "executionQuantity: 4"); } @Before public void beforeEveryTest() { adminAPI.createInstrument("name: instrument"); registrationAPI.createUser("user"); registrationAPI.createUser("marketMaker", "accountType: MARKET_MAKER"); tradingUI.loginAsLive("user"); }

Slide 76

Slide 76 text

Language of the Problem Domain - DSL public void placeOrder(final String... args) { final DslParams params = new DslParams(args, new OptionalParam("type").setDefault("Limit").setAllowedValues("limit", "market", "StopMarket"), new OptionalParam("side").setDefault("Buy").setAllowedValues("buy", "sell"), new OptionalParam("price"), new OptionalParam("triggerPrice"), new OptionalParam("quantity"), new OptionalParam("stopProfitOffset"), new OptionalParam("stopLossOffset"), new OptionalParam("confirmFeedback").setDefault("true")); getDealTicketPageDriver().placeOrder(params.value("type"), params.value("side"), params.value("price"), params.value("triggerPrice"), params.value("quantity"), params.value("stopProfitOffset"), params.value("stopLossOffset")); if (params.valueAsBoolean("confirmFeedback")) { getDealTicketPageDriver().clickOrderFeedbackConfirmationButton(); } LOGGER.debug("placeOrder(" + Arrays.deepToString(args) + ")"); }

Slide 77

Slide 77 text

Language of the Problem Domain - DSL @Test public void shouldSupportPlacingValidBuyAndSellLimitOrders() { tradingUI.showDealTicket("instrument"); tradingUI.dealTicket.placeOrder("type: limit", ”bid: 4@10”); tradingUI.dealTicket.checkFeedbackMessage("You have successfully sent a limit order to buy 4.00 contracts at 10.0"); tradingUI.dealTicket.dismissFeedbackMessage(); tradingUI.dealTicket.placeOrder("type: limit", ”ask: 4@9”); tradingUI.dealTicket.checkFeedbackMessage("You have successfully sent a limit order to sell 4.00 contracts at 9.0"); } @Test public void shouldSuccessfullyPlaceAnImmediateOrCancelBuyMarketOrder() { fixAPIMarketMaker.placeMassOrder("instrument", "ask: 11@52", "ask: 10@51", "ask: 10@50", "bid: 10@49"); fixAPI.placeOrder("instrument", "side: buy", "quantity: 4", "goodUntil: Immediate", "allowUnmatched: true"); fixAPI.waitForExecutionReport("executionType: Fill", "orderStatus: Filled", "side: buy", "quantity: 4", "matched: 4", "remaining: 0", "executionPrice: 50", "executionQuantity: 4"); }

Slide 78

Slide 78 text

Language of the Problem Domain - DSL @Test public void shouldSupportPlacingValidBuyAndSellLimitOrders() { tradingUI.showDealTicket("instrument"); tradingUI.dealTicket.placeOrder("type: limit", ”bid: 4@10”); tradingUI.dealTicket.checkFeedbackMessage("You have successfully sent a limit order to buy 4.00 contracts at 10.0"); tradingUI.dealTicket.dismissFeedbackMessage(); tradingUI.dealTicket.placeOrder("type: limit", ”ask: 4@9”); tradingUI.dealTicket.checkFeedbackMessage("You have successfully sent a limit order to sell 4.00 contracts at 9.0"); } @Test public void shouldSuccessfullyPlaceAnImmediateOrCancelBuyMarketOrder() { fixAPIMarketMaker.placeMassOrder("instrument", "ask: 11@52", "ask: 10@51", "ask: 10@50", "bid: 10@49"); fixAPI.placeOrder("instrument", "side: buy", "quantity: 4", "goodUntil: Immediate", "allowUnmatched: true"); fixAPI.waitForExecutionReport("executionType: Fill", "orderStatus: Filled", "side: buy", "quantity: 4", "matched: 4", "remaining: 0", "executionPrice: 50", "executionQuantity: 4"); }

Slide 79

Slide 79 text

Language of the Problem Domain - DSL @Channel(fixApi, dealTicket, publicApi) @Test public void shouldSuccessfullyPlaceAnImmediateOrCancelBuyMarketOrder() { trading.placeOrder("instrument", "side: buy", “price: 123.45”, "quantity: 4", "goodUntil: Immediate”); trading.waitForExecutionReport("executionType: Fill", "orderStatus: Filled", "side: buy", "quantity: 4", "matched: 4", "remaining: 0", "executionPrice: 123.45", "executionQuantity: 4"); }

Slide 80

Slide 80 text

Language of the Problem Domain - DSL @Channel(fixApi, dealTicket, publicApi) @Test public void shouldSuccessfullyPlaceAnImmediateOrCancelBuyMarketOrder() { trading.placeOrder("instrument", "side: buy", “price: 123.45”, "quantity: 4", "goodUntil: Immediate”); trading.waitForExecutionReport("executionType: Fill", "orderStatus: Filled", "side: buy", "quantity: 4", "matched: 4", "remaining: 0", "executionPrice: 123.45", "executionQuantity: 4"); }

Slide 81

Slide 81 text

Properties of Good Acceptance Tests • “What” not “How” • Isolated from other tests • Repeatable • Uses the language of the problem domain • Tests ANY change • Efficient

Slide 82

Slide 82 text

Properties of Good Acceptance Tests • “What” not “How” • Isolated from other tests • Repeatable • Uses the language of the problem domain • Tests ANY change • Efficient

Slide 83

Slide 83 text

Testing with Time • Test Cases should be deterministic • Time is a problem for determinism - There are two options: • Ignore time • Control time

Slide 84

Slide 84 text

Testing With Time - Ignore Time Mechanism Filter out time-based values in your test infrastructure so that they are ignored Pros: • Simple! Cons: • Can miss errors • Prevents any hope of testing complex time-based scenarios

Slide 85

Slide 85 text

Mechanism Treat Time as an external dependency, like any external system - and Fake it! Pros: • Very Flexible! • Can simulate any time-based scenario, with time under the control of the test case. Cons: • Slightly more complex infrastructure Testing With Time - Controlling Time

Slide 86

Slide 86 text

Testing With Time - Controlling Time @Test public void shouldBeOverdueAfterOneMonth() { book = library.borrowBook(“Continuous Delivery”); assertFalse(book.isOverdue()); time.travel(“+1 week”); assertFalse(book.isOverdue()); time.travel(“+4 weeks”); assertTrue(book.isOverdue()); }

Slide 87

Slide 87 text

Testing With Time - Controlling Time @Test public void shouldBeOverdueAfterOneMonth() { book = library.borrowBook(“Continuous Delivery”); assertFalse(book.isOverdue()); time.travel(“+1 week”); assertFalse(book.isOverdue()); time.travel(“+4 weeks”); assertTrue(book.isOverdue()); }

Slide 88

Slide 88 text

Testing With Time - Controlling Time

Slide 89

Slide 89 text

Testing With Time - Controlling Time Test Infrastructure Test Case Test Case Test Case Test Case System Under Test public void someTimeDependentMethod() { time = System.getTime(); } System Under Test

Slide 90

Slide 90 text

Testing With Time - Controlling Time Test Infrastructure Test Case Test Case Test Case Test Case System Under Test include Clock; public void someTimeDependentMethod() { time = Clock.getTime(); } System Under Test

Slide 91

Slide 91 text

Testing With Time - Controlling Time Test Infrastructure Test Case Test Case Test Case Test Case System Under Test include Clock; public void someTimeDependentMethod() { time = Clock.getTime(); } public class Clock { public static clock = new SystemClock(); public static void setTime(long newTime) { clock.setTime(newTime); } public static long getTime() { return clock.getTime(); } System Under Test

Slide 92

Slide 92 text

Testing With Time - Controlling Time Test Infrastructure Test Case Test Case Test Case Test Case System Under Test include Clock; public void someTimeDependentMethod() { time = Clock.getTime(); } public void onInit() { // Remote Call - back-channel systemUnderTest.setClock(new TestClock()); } public void time-travel(String time) { long newTime = parseTime(time); // Remote Call - back-channel systemUnderTest.setTime(newTime); } Test Infrastructure Back-Channel public class Clock { public static clock = new SystemClock(); public static void setTime(long newTime) { clock.setTime(newTime); } public static long getTime() { return clock.getTime(); } System Under Test

Slide 93

Slide 93 text

Test Environment Types • Some Tests need special treatment. • Tag Tests with properties and allocate them dynamically:

Slide 94

Slide 94 text

Test Environment Types • Some Tests need special treatment. • Tag Tests with properties and allocate them dynamically: @TimeTravel @Test public void shouldDoSomethingThatNeedsFakeTime() … @Destructive @Test public void shouldDoSomethingThatKillsPartOfTheSystem() … @FPGA(version=1.3) @Test public void shouldDoSomethingThatRequiresSpecificHardware() …

Slide 95

Slide 95 text

Test Environment Types • Some Tests need special treatment. • Tag Tests with properties and allocate them dynamically: @TimeTravel @Test public void shouldDoSomethingThatNeedsFakeTime() … @Destructive @Test public void shouldDoSomethingThatKillsPartOfTheSystem() … @FPGA(version=1.3) @Test public void shouldDoSomethingThatRequiresSpecificHardware() …

Slide 96

Slide 96 text

Test Environment Types

Slide 97

Slide 97 text

Test Environment Types

Slide 98

Slide 98 text

Properties of Good Acceptance Tests • “What” not “How” • Isolated from other tests • Repeatable • Uses the language of the problem domain • Tests ANY change • Efficient

Slide 99

Slide 99 text

Properties of Good Acceptance Tests • “What” not “How” • Isolated from other tests • Repeatable • Uses the language of the problem domain • Tests ANY change • Efficient

Slide 100

Slide 100 text

Production-like Test Environments

Slide 101

Slide 101 text

Production-like Test Environments

Slide 102

Slide 102 text

Production-like Test Environments

Slide 103

Slide 103 text

Production-like Test Environments

Slide 104

Slide 104 text

Production-like Test Environments

Slide 105

Slide 105 text

Production-like Test Environments

Slide 106

Slide 106 text

Production-like Test Environments

Slide 107

Slide 107 text

Make Test Cases Internally Synchronous

Slide 108

Slide 108 text

Make Test Cases Internally Synchronous • Look for a “Concluding Event” listen for that in your DSL to report an async call as complete

Slide 109

Slide 109 text

Make Test Cases Internally Synchronous Example DSL level Implementation… public String placeOrder(String params…) { orderSent = sendAsyncPlaceOrderMessage(parseOrderParams(params)); return waitForOrderConfirmedOrFailOnTimeOut(orderSent); } • Look for a “Concluding Event” listen for that in your DSL to report an async call as complete

Slide 110

Slide 110 text

Make Test Cases Internally Synchronous Example DSL level Implementation… public String placeOrder(String params…) { orderSent = sendAsyncPlaceOrderMessage(parseOrderParams(params)); return waitForOrderConfirmedOrFailOnTimeOut(orderSent); } • Look for a “Concluding Event” listen for that in your DSL to report an async call as complete

Slide 111

Slide 111 text

Make Test Cases Internally Synchronous • Look for a “Concluding Event” listen for that in your DSL to report an async call as complete • If you really have to, implement a 
 “poll-and-timeout” mechanism in your test-infrastructure • Never, Never, Never, put a “wait(xx)” and expect your tests to be (a) Reliable or (b) Efficient! • Look for a “Concluding Event” listen for that in your DSL to report an async call as complete

Slide 112

Slide 112 text

Make Test Cases Internally Synchronous • Look for a “Concluding Event” listen for that in your DSL to report an async call as complete • If you really have to, implement a 
 “poll-and-timeout” mechanism in your test-infrastructure • Never, Never, Never, put a “wait(xx)” and expect your tests to be (a) Reliable or (b) Efficient! • Look for a “Concluding Event” listen for that in your DSL to report an async call as complete Anti-Pattern!

Slide 113

Slide 113 text

Scaling-Up Artifact Repository Deployment Pipeline Acceptance Commit Component Performance System Performance Staging Env. Deployment App. Production Env. Deployment App. Source Repository Manual Test Env. Deployment App.

Slide 114

Slide 114 text

Scaling-Up Artifact Repository Deployment Pipeline Acceptance Commit Component Performance System Performance Staging Env. Deployment App. Production Env. Deployment App. Source Repository Manual Test Env. Deployment App. Deployment Pipeline Commit Manual Test Env. Deployment App. Artifact Repository Acceptance Acceptance Test Environment

Slide 115

Slide 115 text

Scaling-Up Artifact Repository Deployment Pipeline Acceptance Commit Component Performance System Performance Staging Env. Deployment App. Production Env. Deployment App. Source Repository Manual Test Env. Deployment App. Deployment Pipeline Commit Manual Test Env. Deployment App. Artifact Repository Acceptance Acceptance Test Environment A A

Slide 116

Slide 116 text

Scaling-Up Artifact Repository Deployment Pipeline Acceptance Commit Component Performance System Performance Staging Env. Deployment App. Production Env. Deployment App. Source Repository Manual Test Env. Deployment App. Deployment Pipeline Commit Manual Test Env. Deployment App. Artifact Repository Acceptance Acceptance Test Environment A A

Slide 117

Slide 117 text

Scaling-Up Artifact Repository Deployment Pipeline Acceptance Commit Component Performance System Performance Staging Env. Deployment App. Production Env. Deployment App. Source Repository Manual Test Env. Deployment App. Deployment Pipeline Commit Manual Test Env. Deployment App. Artifact Repository Acceptance Acceptance Test Environment Test Host Test Host Test Host Test Host Test Host A A

Slide 118

Slide 118 text

Scaling-Up Artifact Repository Deployment Pipeline Acceptance Commit Component Performance System Performance Staging Env. Deployment App. Production Env. Deployment App. Source Repository Manual Test Env. Deployment App. Deployment Pipeline Commit Manual Test Env. Deployment App. Artifact Repository Acceptance Acceptance Acceptance Test Environment Test Host Test Host Test Host Test Host Test Host A A

Slide 119

Slide 119 text

Anti-Patterns in Acceptance Testing

Slide 120

Slide 120 text

Anti-Patterns in Acceptance Testing • Don’t use UI Record-and-playback Systems

Slide 121

Slide 121 text

Anti-Patterns in Acceptance Testing • Don’t use UI Record-and-playback Systems • Don’t Record-and-playback production data. This has a role, but it is NOT Acceptance Testing

Slide 122

Slide 122 text

Anti-Patterns in Acceptance Testing • Don’t use UI Record-and-playback Systems • Don’t Record-and-playback production data. This has a role, but it is NOT Acceptance Testing • Don’t dump production data to your test systems, instead define the absolute minimum data that you need

Slide 123

Slide 123 text

Anti-Patterns in Acceptance Testing • Don’t use UI Record-and-playback Systems • Don’t Record-and-playback production data. This has a role, but it is NOT Acceptance Testing • Don’t dump production data to your test systems, instead define the absolute minimum data that you need • Don’t assume Nasty Automated Testing Products(tm) will do what you need. Be very sceptical about them. Start with YOUR strategy and evaluate tools against that.

Slide 124

Slide 124 text

Anti-Patterns in Acceptance Testing • Don’t use UI Record-and-playback Systems • Don’t Record-and-playback production data. This has a role, but it is NOT Acceptance Testing • Don’t dump production data to your test systems, instead define the absolute minimum data that you need • Don’t assume Nasty Automated Testing Products(tm) will do what you need. Be very sceptical about them. Start with YOUR strategy and evaluate tools against that. • Don’t have a separate Testing/QA team! Quality is down to everyone - Developers own Acceptance Tests!!!

Slide 125

Slide 125 text

Anti-Patterns in Acceptance Testing • Don’t use UI Record-and-playback Systems • Don’t Record-and-playback production data. This has a role, but it is NOT Acceptance Testing • Don’t dump production data to your test systems, instead define the absolute minimum data that you need • Don’t assume Nasty Automated Testing Products(tm) will do what you need. Be very sceptical about them. Start with YOUR strategy and evaluate tools against that. • Don’t have a separate Testing/QA team! Quality is down to everyone - Developers own Acceptance Tests!!! • Don’t let every Test start and init the app. Optimise for Cycle-Time, be efficient in your use of test environments.

Slide 126

Slide 126 text

Anti-Patterns in Acceptance Testing • Don’t use UI Record-and-playback Systems • Don’t Record-and-playback production data. This has a role, but it is NOT Acceptance Testing • Don’t dump production data to your test systems, instead define the absolute minimum data that you need • Don’t assume Nasty Automated Testing Products(tm) will do what you need. Be very sceptical about them. Start with YOUR strategy and evaluate tools against that. • Don’t have a separate Testing/QA team! Quality is down to everyone - Developers own Acceptance Tests!!! • Don’t let every Test start and init the app. Optimise for Cycle-Time, be efficient in your use of test environments. • Don’t include Systems outside of your control in your Acceptance Test Scope

Slide 127

Slide 127 text

Anti-Patterns in Acceptance Testing • Don’t use UI Record-and-playback Systems • Don’t Record-and-playback production data. This has a role, but it is NOT Acceptance Testing • Don’t dump production data to your test systems, instead define the absolute minimum data that you need • Don’t assume Nasty Automated Testing Products(tm) will do what you need. Be very sceptical about them. Start with YOUR strategy and evaluate tools against that. • Don’t have a separate Testing/QA team! Quality is down to everyone - Developers own Acceptance Tests!!! • Don’t let every Test start and init the app. Optimise for Cycle-Time, be efficient in your use of test environments. • Don’t include Systems outside of your control in your Acceptance Test Scope • Don’t Put ‘wait()’ instructions in your tests hoping it will solve intermittency

Slide 128

Slide 128 text

Tricks for Success

Slide 129

Slide 129 text

Tricks for Success • Do Ensure That Developers Own the Tests

Slide 130

Slide 130 text

Tricks for Success • Do Ensure That Developers Own the Tests • Do Focus Your Tests on “What” not “How”

Slide 131

Slide 131 text

Tricks for Success • Do Ensure That Developers Own the Tests • Do Focus Your Tests on “What” not “How” • Do Think of Your Tests as “Executable Specifications”

Slide 132

Slide 132 text

Tricks for Success • Do Ensure That Developers Own the Tests • Do Focus Your Tests on “What” not “How” • Do Think of Your Tests as “Executable Specifications” • Do Make Acceptance Testing Part of your “Definition of Done”

Slide 133

Slide 133 text

Tricks for Success • Do Ensure That Developers Own the Tests • Do Focus Your Tests on “What” not “How” • Do Think of Your Tests as “Executable Specifications” • Do Make Acceptance Testing Part of your “Definition of Done” • Do Keep Tests Isolated from one-another

Slide 134

Slide 134 text

Tricks for Success • Do Ensure That Developers Own the Tests • Do Focus Your Tests on “What” not “How” • Do Think of Your Tests as “Executable Specifications” • Do Make Acceptance Testing Part of your “Definition of Done” • Do Keep Tests Isolated from one-another • Do Keep Your Tests Repeatable

Slide 135

Slide 135 text

Tricks for Success • Do Ensure That Developers Own the Tests • Do Focus Your Tests on “What” not “How” • Do Think of Your Tests as “Executable Specifications” • Do Make Acceptance Testing Part of your “Definition of Done” • Do Keep Tests Isolated from one-another • Do Keep Your Tests Repeatable • Do Use the Language of the Problem Domain - Do try the DSL approach, whatever your tech.

Slide 136

Slide 136 text

Tricks for Success • Do Ensure That Developers Own the Tests • Do Focus Your Tests on “What” not “How” • Do Think of Your Tests as “Executable Specifications” • Do Make Acceptance Testing Part of your “Definition of Done” • Do Keep Tests Isolated from one-another • Do Keep Your Tests Repeatable • Do Use the Language of the Problem Domain - Do try the DSL approach, whatever your tech. • Do Stub External Systems

Slide 137

Slide 137 text

Tricks for Success • Do Ensure That Developers Own the Tests • Do Focus Your Tests on “What” not “How” • Do Think of Your Tests as “Executable Specifications” • Do Make Acceptance Testing Part of your “Definition of Done” • Do Keep Tests Isolated from one-another • Do Keep Your Tests Repeatable • Do Use the Language of the Problem Domain - Do try the DSL approach, whatever your tech. • Do Stub External Systems • Do Test in “Production-Like” Environments

Slide 138

Slide 138 text

Tricks for Success • Do Ensure That Developers Own the Tests • Do Focus Your Tests on “What” not “How” • Do Think of Your Tests as “Executable Specifications” • Do Make Acceptance Testing Part of your “Definition of Done” • Do Keep Tests Isolated from one-another • Do Keep Your Tests Repeatable • Do Use the Language of the Problem Domain - Do try the DSL approach, whatever your tech. • Do Stub External Systems • Do Test in “Production-Like” Environments • Do Make Instructions Appear Synchronous at the Level of the Test Case

Slide 139

Slide 139 text

Tricks for Success • Do Ensure That Developers Own the Tests • Do Focus Your Tests on “What” not “How” • Do Think of Your Tests as “Executable Specifications” • Do Make Acceptance Testing Part of your “Definition of Done” • Do Keep Tests Isolated from one-another • Do Keep Your Tests Repeatable • Do Use the Language of the Problem Domain - Do try the DSL approach, whatever your tech. • Do Stub External Systems • Do Test in “Production-Like” Environments • Do Make Instructions Appear Synchronous at the Level of the Test Case • Do Test for ANY change

Slide 140

Slide 140 text

Tricks for Success • Do Ensure That Developers Own the Tests • Do Focus Your Tests on “What” not “How” • Do Think of Your Tests as “Executable Specifications” • Do Make Acceptance Testing Part of your “Definition of Done” • Do Keep Tests Isolated from one-another • Do Keep Your Tests Repeatable • Do Use the Language of the Problem Domain - Do try the DSL approach, whatever your tech. • Do Stub External Systems • Do Test in “Production-Like” Environments • Do Make Instructions Appear Synchronous at the Level of the Test Case • Do Test for ANY change • Do Keep your Tests Efficient

Slide 141

Slide 141 text

Q&A http://www.continuous-delivery.co.uk Dave Farley http://www.davefarley.net @davefarley77