Skip to content

Instantly share code, notes, and snippets.

@lalunamel

lalunamel/possible-intro-to-testing.md

Created November 15, 2018 16:38
Show Gist options
  • Save lalunamel/9c2ad155949030d9b080a60c0bb71ab8 to your computer and use it in GitHub Desktop.
Save lalunamel/9c2ad155949030d9b080a60c0bb71ab8 to your computer and use it in GitHub Desktop.
Download ZIP
Possible Mobile Talk: Intro to Testing
Raw
possible-intro-to-testing.md

Intro to Testing

Adapted from a lesson I wrote/taught at Turing: http://frontend.turing.io/lessons/module-2/test-driven-development.html

Game Plan

  • Something
  • Look at the structure of a test and the testing lifecycle
  • Write some tests!
  • Resources

How My Talks Work

Vocab

  • TDD Test Driven Development / Design
  • Four Phase Test A test that is organized into the phases [Setup, Execution, Assertion, Teardown]
  • Assertion An expression containing some testable logic
  • Assertion Library A package of assertion functionality. Usually distinct from a Testing Framework
  • Testing Framework A library that determines how tests are organized and executed
  • Red Green Refactor The process of writing a failing test, making it pass, then refactoring the tests and/or implementation with confidence

Motivation

  • Motivating example
    • Macro
      • Long feedback loop
      • Expense of defects: dev <-> prod continuum
      • Risk that goes along with ^ expense ^
      • Developer confidence
    • Micro
      • Did I write the correct code?
      • Did I break something?
      • How is this supposed to work?

Why

  • Computers are fast and accurate. This is what they're good at.
  • Design first, code second
  • Designing for tests creates better interfaces
    • If writing tests is hard, that's a smell
    • Generally, the same things that make code easy to test make it easy to reason about.
  • De-risking, developer confidence, reducing cost of defects
  • Answers the question "Did I break anything?"
  • Provides documentation
  • OPINION: It just plain makes better code

Why Not

  • Tests are not features - they don't push the product forward or make money
  • It takes time to write tests - time you could be using to do things that make money
  • It takes rigor and principle to write tests
    • You can certainly write tests without rigor, but you're not going to get a whole lot of benefit
  • Ramp up time

What

Lets get into it!

The Testing Pyramid

  • Unit
  • Integration
  • UI

Risk/Cost/Flake/Speed comparison

What Not To Test

  • Slow stuff
    • Network
    • Database
  • Stuff you don't own
    • APIs you depend on
    • The framework you use
  • Private functions

Structure of a Test

Good tests have Four Phases:

  1. Setup - Setup the conditions required to execute the action on your SUT
  2. Execution - Execute some action on your SUT
  3. Assertion - Assert that the action you did had the results you expect
  4. Tear Down - Clean up any resources you used in your test (this is done automatically most of the time)

All four of these phases deal with the Subject Under Test (SUT, or just subject). Most tests you write will not need the Tear Down phase, but it’s good to know that step can be there.

Demo!

https://github.com/lalunamel/MapTDD

Reasons Why Testing Is Hard

In the abstract, writing tests forces you to pay costs now instead of later. Have a codebase that doesn't use DI, has giant classes, and lots of state? Testing that stuff means paying the cost now, rather than paying a little now, and a little next time, and the next time, etc.

Some Interesting Philosophical Discussions You Can Have At Home

Here are some interesting philosophical discussions you can have at home around the dinner table:

Resources

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment