9 Common Misconceptions about TDD

class: center, middle, cover, dark

# .big[9 Common Misconceptions about TDD]

##.mtf[Mage Test Fest]

---
class: middle

.aside.width100[![Hair Schmengler](images/hair-schmengler-bw.png)]
.left[
#Fabian Schmengler

Developer and partner at .integergreen[integer_net]

Testing Magento since 2011

.twitter[@fschmengler]

.big[.icon[![](images/middle_solution_specialist_m2.png)![](images/middle_professional_developer_m2.png)].whiteicon.icon[![](images/master-2017.png) ![](images/master-2018.png)]]

]
---
layout: true
.footer[.left[Fabian Schmengler /> **9 Common misconceptions about TDD**] .right[@fschmengler]]
---
class: center

.width33[![Straw man?](images/straw-man.png)]

Disclaimer: Beware of straw men
---

# ☼ EINS
#.huge[I have tests, thus I do TDD]

---

#TDD
.aside.width50[![](images/the-location-of-the-1724293_1280.png)]
- Test first

- Tests *guide* development

#Not TDD
.aside.width50[![](images/list-2389219_1280.png)]

- Test after

- Test *verify* development

---

# ☼ ZWEI
#.huge[Write test, then implement feature]

---

# Red-Green-Refactor

## In Short Cycles!

1. .red[Write failing test]
2. .green[Make it pass]
3. .blue[Make it good]

---

# Red-Green-Refactor

## In Short Cycles!

1. .red[Write failing test] ⬅️ one little test at at time
2. .green[Make it pass]
3. .blue[Make it good]

.grid3[
.col1.width50[![](images/policeman-23796_1280.png)]
]
---

# Red-Green-Refactor

## In Short Cycles!

1. .red[Write failing test] ⬅️ one little test at at time
2. .green[Make it pass] ⬅️ stupid hacky solution
3. .blue[Make it good]

.grid3[
.col1.width50[![](images/policeman-23796_1280.png)]
.col2.width50[![](images/technician-3577933_1280.png)]
]

---

# Red-Green-Refactor

## In Short Cycles!

1. .red[Write failing test] ⬅️ one little test at at time
2. .green[Make it pass] ⬅️ stupid hacky solution
3. .blue[Make it good] ⬅️ well designed solution

.grid3[
.col1.width50[![](images/policeman-23796_1280.png)]
.col2.width50[![](images/technician-3577933_1280.png)]
.col3.width50[![](images/plumber-35611_1280.png)]
]

---

# ☼ DREI
#.huge[No code is ever written without tests]

---

# Experiments, "Spikes"

.aside.width66[![](images/chemicals-2029784_960_720.png)]

- Try out the framework
- Proof of concept
- Throwaway code

---

# Other ways to experiment

.aside-s.width66[![](images/man-37497_1280.png)]
## Exploratory tests
- Use failing assertions to see real results of unknown operation. e.g.:
```php
$this->assertEquals([[], [], []], $result);
```

.clear[
##REPL (Read-Execute-Print-Loop)
.aside-s.width66[![](images/bash-148836_1280.png)]
- JS: browser console
- PHP: `n98-magerun2 dev:console`
]
---

# ☼ VIER
#.huge[When the tests pass, we are done]

---

# Iterative vs. Incremental
.aside.width100[![](images/caveman-159359_1280.png)]
- Always refactor
- Started with a stupid solution
- Design evolves through refactoring

---

# Changeability & Replacability
.aside.width100[![](images/sneakers-310942_1280.png)]
<blockquote class="twitter-tweet" data-lang="de">If I change out of my galoshes and in to my tennis shoes, I'm preparing to move faster. Sure, I could run the race in my galoshes. Sure, it will take me a few seconds to take them off. But I'm betting that the cost of changing the shoes will be more than made up during the race.— GeePaw Hill (@GeePawHill) <a href="https://twitter.com/GeePawHill/status/1086224864128757760?ref_src=twsrc%5Etfw">18. Januar 2019</a></blockquote>

---

# ☼ FÜNF
#.huge[TDD is a testing technique]

---

# Test Driven ⬆️**Development**

.aside.width50[![](images/sign-48703_1280.png)]

- A way to write code
- Tests are means to an end
- (and a welcome side effect)

---

# ☼ SECHS
#.huge[No upfront design needed]

---

# TDD does not replace
.aside.width100[![](images/woman-1455991_960_720.png)]

- Requirement analysis
- Domain Modeling
- System Design
- API Design

=> WHAT to build

**Architects are not becoming unemployed**

---

# ☼ SIEBEN
#.huge[Mock all the collaborators]

---

# Isolation

.aside.width100[![isolated bird](images/cat-1456962_1280.png)]

## Isolation From WHAT?
- External resources: **certainly**
- Framework: ***mostly***

*Except for integration tests*
- Libraries: *rather not*
   
   *No implementation details.*

---

# Avoid the Mocking Hell

.aside.width100[![](images/leaf-46540_1280.png)]

- Keep Magento *dependencies* to a *minimum*
- Mock/stub *service contracts* (API interfaces), not concrete classes
- Write *adapters* for complex or insufficient API

*Mock or fake those*

---

# ☼ ACHT
#.huge[A *unit* is a class]

---

# Unit Test Subject

.aside.width100[![](images/switch-23328_1280.png)]
- Public API of *components*
- e.g. Service as Facade, and its return types
- No unit tests for framework integration layer:
  - Controllers
  - Plugins
  - Observers
  - Blocks
  - Resource Models, Repositories
- Those remain *dumb* and use our components.

---

# Unit Test

.aside.width100[![](images/graphic-3619544_1280.png)]
- Test behavior, not implementation
- *1 Test Case != 1 Class*
- *1 Test != 1 Method*

---

# Example feature: Subscriptions
.aside.width100[![](images/shopping-3613689_1280.png)]
- Orders can be turned into subscriptions
- Subsequent orders are placed automatically

## Behavior to test

- A subscription is created if an order has been marked as subscription during checkout
- Orders are created for active subscriptions with due date

---

```text
Subscriptions
├── Cron
│   └── HandleSubscriptionsCron.php          ⬅️ integration layer
├── Model
│   ├── `CreateSubscription.php               ⬅️ services as public API`
│   ├── `CreateOrders.php`
│   ├── Subscription.php                     ⬅️ implementation details
│   ├── SubscriptionPeriod.php
│   ├── SubscriptionStatus.php
│   ├── SubscriptionRepository.php           ⬅️ integration layer, mocked in test
│   └── SubscriptionRepositoryInterface.php
├── Plugin
│   └── PlaceOrderPlugin.php                 ⬅️ integration layer
└── Test
    ├── Unit
    │   ├── `CreateSubscriptionTest.php       ⬅️ test behavior`
    │   └── `CreateOrdersTest.php`
    └── Integration
        ├── CronTest.php                     ⬅️ test framework integration
        ├── PlaceOrderTest.php
        └── SubscriptionRepositoryTest.php
```

---

```text
Subscriptions
├── Cron
│   └── `HandleSubscriptionsCron.php          ⬅️ integration layer`
├── Model
│   ├── CreateSubscription.php               ⬅️ services as public API
│   ├── CreateOrders.php`
│   ├── Subscription.php                     ⬅️ implementation details
│   ├── SubscriptionPeriod.php
│   ├── SubscriptionStatus.php
│   ├── SubscriptionRepository.php           ⬅️ integration layer, mocked in test
│   └── SubscriptionRepositoryInterface.php
├── Plugin
│   └── `PlaceOrderPlugin.php                 ⬅️ integration layer`
└── Test
    ├── Unit
    │   ├── CreateSubscriptionTest.php       ⬅️ test behavior
    │   └── CreateOrdersTest.php`
    └── Integration
        ├── `CronTest.php                     ⬅️ test framework integration`
        ├── `PlaceOrderTest.php`
        └── SubscriptionRepositoryTest.php

```

---

```text
Subscriptions
├── Cron
│   └── HandleSubscriptionsCron.php          ⬅️ integration layer
├── Model
│   ├── CreateSubscription.php               ⬅️ services as public API
│   ├── CreateOrders.php
│   ├── Subscription.php                     ⬅️ implementation details
│   ├── SubscriptionPeriod.php
│   ├── SubscriptionStatus.php
│   ├── `SubscriptionRepository.php           ⬅️ integration layer, mocked in test`
│   └── `SubscriptionRepositoryInterface.php`
├── Plugin
│   └── PlaceOrderPlugin.php                 ⬅️ integration layer
└── Test
    ├── Unit
    │   ├── CreateSubscriptionTest.php       ⬅️ test behavior
    │   └── CreateOrdersTest.php
    └── Integration
        ├── CronTest.php                     `⬅️ test framework integration`
        ├── PlaceOrderTest.php
        └── `SubscriptionRepositoryTest.php`
```

---

```text
Subscriptions
├── Cron
│   └── HandleSubscriptionsCron.php          ⬅️ integration layer
├── Model
│   ├── CreateSubscription.php               ⬅️ services as public API
│   ├── CreateOrders.php
│   ├── `Subscription.php                     ⬅️ implementation details`
│   ├── `SubscriptionPeriod.php`
│   ├── `SubscriptionStatus.php`
│   ├── SubscriptionRepository.php           ⬅️ integration layer, mocked in test
│   └── SubscriptionRepositoryInterface.php
├── Plugin
│   └── PlaceOrderPlugin.php                 ⬅️ integration layer
└── Test
    ├── Unit
    │   ├── CreateSubscriptionTest.php       ⬅️ test behavior
    │   └── CreateOrdersTest.php
    └── Integration
        ├── CronTest.php                     ⬅️ test framework integration
        ├── PlaceOrderTest.php
        └── SubscriptionRepositoryTest.php
```

<!---

```php
class CreateSubscription {
  public function __construct(SubscriptionRepositoryInterface $repo);
  public function execute(OrderInterface $order, SubscriptionPeriod $period);
}

class CreateOrders 
{
 public function __construct(
 SubscriptionRepositoryInterface $repo,
 OrderManagementInterface $orderManagement
 );
 public function execute();
}
```
-->
<!---

```
Subscriptions
├── `Api` ⬅️ API *may* be exposed to other modules and REST API
│   └── Data
│   │   └── SubscriptionInterface.php
│   └── CreateSubscriptionInterface.php
│   └── HandleSubscriptionsInterface.php
│   └── SubscriptionRepositoryInterface.php
├── ...
``` 
-->
---

# Exception

*Testing implementation details can aid development and small scale refactoring.*

.aside.width66[![](images/bird-3077427_960_720.png)]

BUT those tests can be *thrown away* when their job is done! Otherwise they stay only as *maintenance burden*.

##Let them go!

---

# ☼ NEUN
#.huge[BDD is better than TDD]

---

## TDD 
.aside.width50[![](images/laptop-40935_1280.png)]
-  Helps with code design
-  Focus on developers

## BDD/ATDD
.aside.width50.rounded[![](images/blank-profile-picture-973460_1280.png)]
- Helps with requirement analysis
- Focus on users

---

# Test Behavior

.aside.width100[![](images/shrug-153698_1280.png)]

- Ideas are not contradictional!
- With TDD we should test *behavior* as well
- And why not both?

---

# Tests in Natural Language

.aside.width100[![](images/cucumber-161610_1280.png)]

- Who is really *writing* their tests together with the customer?
- Expressive test code is possible without Gherkin

---

## Gherkin
```gherkin
Scenario 1: Refunded items should be returned to stock
Given that a customer previously bought a black sweater from me
And I have three black sweaters in stock.
When they return the black sweater for a refund
Then I should have four black sweaters in stock.
```

## PHPUnit
```php
public function test_refunded_items_should_be_returned_to_stock()
{
  $this->given_that_a_customer_previously_bought_a_black_sweater_from_me();
  $this->and_I_have_three_black_sweaters_in_stock();
  $this->when_they_return_the_black_sweater_for_a_refund();
  $this->then_I_should_have_four_black_sweaters_in_stock();
}
```

---
class: dark
background-image: url(images/feuer-frei-bw.png)

# ☼ AUS

---
class: center,dark

##Coming <del>soon</del> <ins>when it's done</ins>:
# Test Driven Magento by Example

.white[`https://tddwizard.com/`]

.twitter[@fschmengler]

---
class: dark

# Image sources

- Rammstein concert: [Matt Foster](https://www.flickr.com/photos/70385183@N00/146215535/) CC-BY 2.0 (colors modified)
- Cliparts: pixaby.com (Pixaby Licence, free for commercial usage)