Old Solutions to New Testing Problems

Old Solutions
to
New Testing Problems
Josh Justice
1 Old Solutions to New Testing Problems - Assert(js) 2019 - @CodingItWrong

JavaScript test tooling
has improved a lot.

The problem now:
Test Maintainability

How can we learn how
to write more
maintainable tests?

"Well actually,
in Ruby we write
tests like this—"

PATTERNS

Five Patterns

Takeaways
1. New testing approaches
2. Clearer explanation of the benefits
3. Shared language and support

!
"Code Smells"

"Code Smells"
⚠
Warning Signs

import formatAddress from '../formatAddress';
import addresses from '../__sampleData__/addresses';
describe('formatAddress', () => {
it('formats addresses correctly', () => {
let expectedResult;
for (const address of addresses) {
if (address.street2) {
expectedResult = `${address.street1}
${address.street2}
${address.city}, ${address.province} ${address.postalCode}`;
} else {
expectedResult = `${address.street1}
}
expect(formatAddress(address)).toEqual(expectedResult);
}
});
});

Problems
• Tests can be hard to understand
• Tests might have a bug, and you don't test your tests
• If test data changes, not all cases might be executed

⚠
Flexible Test

⚠
Flexible Test
"Using conditional logic to reuse a single test to verify several different
cases."

Solution: Simple Tests
Split the tests into simpler cases, controlling for specific situations.

it('formats an address with two lines correctly', () => {
const address = addresses[0];
const expectedResult = `${address.street1}
${address.street2}
});

it('formats an address with one line correctly', () => {
});

Warning Sign:
⚠
Flexible Test
Solution:
Simple Tests

});
});

Problems
• Can't see the data relevant to what's being tested, have to look in
another file
• Test harder to understand, easier for bugs to sneak through
• Coupled to shared test data; if it changes, test could break or give a
false positive

⚠
Mystery Guest

⚠
Mystery Guest
“The test reader is not able to see the cause and effect between
fixture and verification logic because part of it is done outside the
Test Method.”

⚠
Mystery Guest
“The test reader is not able to see the cause and effect between
FIXTURE and verification logic because part of it is done outside the
Test Method.”

Fixture
“everything we need in place to exercise the [production code]”...“the
pre-conditions of the test”

Shared Fixture
“…reusing the same fixture for several or many tests.”

Fresh Fixture
“Each test constructs its own brand-new test fixture for its own
private use.”

⚠
Mystery Guest
“The test reader is not able to see the cause and effect between fixture
and verification logic because part of it is done outside the Test
Method.”

Solution: set up the data
closer to the test
Several possible approaches using Fresh Fixtures

Approach 1: In-Line Setup
“Each Test Method creates its own Fresh Fixture by [building] exactly
the test fixture it requires.”

const address = {
street1: '101 College Street',
city: 'Toronto',
province: 'ON',
postalCode: 'M5G 1L7'
};
});

Approach 2: Delegated Setup

“Each Test Method creates its own Fresh Fixture by calling Creation
Methods from within the Test Methods.”

function createAddress({ hasStreet2 = false }) {
const address = {
city: 'Toronto',
province: 'ON',
};
if (hasStreet2) {
address.street2 = 'Suite 123';
}
return address;
};

const address = createAddress({ hasStreet2: false });
});

const address = createAddress({ hasStreet2: true });
${address.street2}
});

Approach 3: Implicit Setup
“We build the test fixture common to several tests in the setUp
method."

let address;
beforeEach(() => {
address = {
city: 'Toronto',
province: 'ON',
};
});

});

address.street2 = 'Apt. 317';
${address.street2}
});

⚠
Mystery Guest
Solutions:
1. In-Line Setup
2. Delegated Setup
3. Implicit Setup

it('formats an address correctly', () => {
const address = {
firstName: 'Sally',
lastName: 'Smith',
street1: '80 Spanida Avenue',
street2: '4th Floor',
city: 'Toronto',
province: 'ON',
postalCode: 'M5V 2J4',
country: 'CA'
};
${address.street2}
});

Problems
• Hard to see which fields matter and which don't
• Tests get long

⚠
Irrelevant Information

⚠
“The test exposes a lot of irrelevant details about the fixture that
distract the test reader from what really affects the behavior of the
[system under test].”

General Fixture
“The test builds or references a larger fixture than is needed to verify
the functionality in question.”

Solution 1: Minimal Fixture
“We use the smallest and simplest fixture possible for each test.”

const address = {
- firstName: 'Sally',
- lastName: 'Smith',
city: 'Toronto',
province: 'ON',
- country: 'CA'
};

const address = {
city: 'Toronto',
province: 'ON',
postalCode: 'M5V 2J4'
};

What if that data is still
needed for the code to run?
• Type verification
• Class instance requiring constructor args
• Fields validated by code unrelated to the test

Solution 2: Parameterized
Creation Method
“We set up the test fixture by calling methods that hide the mechanics
of building ready-to-use objects behind Intent-Revealing Names.”
“A Parameterized Creation Method allows the test to pass in some
attributes to be used in the creation of the object. In such a case, we
should pass only those attributes that are expected to affect…the
test's outcome”

const address = createAddress({
city: 'Toronto',
province: 'ON',
postalCode: 'M5V 2J4'
});
${address.street2}
});

Solution 3: Test Data
Creation Libraries

Test Data Bot
!
const { build, sequence } = require('test-data-bot')
const addressBuilder = build('address').fields({
street2: sequence(x => `Suite ${x}`),
city: 'Toronto',
province: 'ON',
})

Test Data Bot
!
const user = addressBuilder({ street2: null })

⚠
Solutions:
1. Minimal Fixture
2. Parameterized Creation Method
3. Test Data Creation Library

import totalOrder from '../totalOrder';
import orders from '../__sampleData__/orders';
describe('totalOrder', () => {
it('calculates the correct total values when there are no line items', () => {
const order = orders[0];
order.lines = [];
const totalValues = totalOrder(order);
expect(totalValues.subtotal).toEqual(0);
expect(totalValues.tax).toEqual(0);
expect(totalValues.total).toEqual(0);
});

it('calculates the correct total values', () => {
const order = orders[0];
expect(totalValues.tax).toBeCloseTo(1.05);
expect(totalValues.total).toBeCloseTo(8.05);
});
});

⚠
Interacting Tests

⚠
Interacting Tests
"Tests depend on other tests in some way…[for example,] a test can be
run as part of a suite but cannot be run by itself"
In our case, a test can be run by itself but cannot be run as part of a
suite.

⚠
Shared Fixture

Solution: Fresh Fixture

Solution: Fresh Fixture
“Each test constructs its own brand-new test fixture for its own
private use.”

it('calculates the correct total values when there are no line items', () => {
const order = _.cloneDeep(orders[0]);
order.lines = [];
expect(totalValues.tax).toEqual(0);
expect(totalValues.total).toEqual(0);
});

const order = _.cloneDeep(orders[0]);
});
});

Warning Sign:
⚠
Interacting Tests
Solution:
Fresh Fixture

const TAX_PERCENT = 0.15;
function totalOrder(order) {
const lineTotals = order.lines.map(line => (
line.pricePerItem * line.quantity
));
const subtotal = lineTotals.reduce((acc, val) => acc + val, 0);
const tax = subtotal * TAX_PERCENT;
const total = subtotal + tax;
return { subtotal, tax, total };
}

describe('totalOrder', () => {
const order = {
lines: [
{
pricePerItem: 5.99,
quantity: 3
},
{
pricePerItem: 7.99,
quantity: 4
}
]
};

const lineTotals = order.lines.map(
line => line.pricePerItem * line.quantity
);
const subtotal = lineTotals.reduce((acc, val) => acc + val);
const tax = subtotal * 0.15;
const total = subtotal + tax;
expect(totalValues.subtotal).toEqual(subtotal);
expect(totalValues.tax).toBeCloseTo(tax);
expect(totalValues.total).toBeCloseTo(total);
});
});

Problems
• If the logic is wrong in one place, it's wrong in both. Is it really
testing?
• Doesn't let you see the intended result at a glance

⚠
Production Logic in Test

⚠
“[If we] use a Calculated Value based on the inputs…we find ourselves
replicating the expected [production] logic inside our test to calculate
the expected values for assertions.”

Solution: Hard-Coded
Test Data

const order = {
lines: [
{
pricePerItem: 2,
quantity: 2
},
{
pricePerItem: 3,
quantity: 1
}
]
};
});

Test Data

Test Data
!

Warning Sign
⚠
Solution
Hard-Coded Test Data

Review: Test Patterns
1. Flexible Test → Simple Tests
2. Mystery Guest → In-Line Setup
3. Irrelevant Information → Minimal Fixture
4. Interacting Tests → Fresh Fixture
5. Production Logic in Test → Hard-Coded Test Data

Takeaways

Let's talk about test
patterns!

Let's talk about test
patterns!
And let's use shared
language!

The deeper takeaway…

Let's connect people
with our rich testing
history.

@CodingItWrong
jjustice@bignerdranch.com
Photos: https://unsplash.com/collections/
8294370/old-solutions-talk

Old Solutions to New Testing Problems

Recommandé

Recommandé

Contenu connexe

Similaire à Old Solutions to New Testing Problems

Similaire à Old Solutions to New Testing Problems (11)

Plus de Josh Justice

Plus de Josh Justice (15)

Dernier

Dernier (20)

Old Solutions to New Testing Problems