Skip to content

Instantly share code, notes, and snippets.

@Auraelius
Last active July 1, 2020 01:50
Show Gist options
  • Save Auraelius/b4430fc8dfb7444ce38e90f2c6e59f2b to your computer and use it in GitHub Desktop.
Save Auraelius/b4430fc8dfb7444ce38e90f2c6e59f2b to your computer and use it in GitHub Desktop.
Extra notes from thinkful's Integration Testing workshop

Topics

  • Testing overview (slides)
  • Intro to Mocha, chai, and supertest (slides)
  • Debugging tests (extra)
  • Tonight's assignment (slides)

Misc details

Testing concepts

  • Four phases of a test
    • Setup data for the request and the expected result
    • Send request to app using supertests
    • Check actual response vs expected response using chai assertions
    • Teardown any setup data
  • Testing mindset: Not "Of course it will work". Instead: "How many ways can I make it fail?"
  • Two test types:
    • Complete specification - Several assertions. Verifies proper operation.
    • Single assertion - Explores only one aspect of behavior. Easier & faster to debug.
  • How much testing is enough?
    • Happy path/smoke test (can be mult-assertion)
    • Error handling
      • Validation (happy & unhappy)
        • Query params required fields
        • Query param type and range
      • Body contents (for POST and PATCH)
    • Be aware of dimishing returns - don't test very unlikely cases or included libraries

As Tolstoy didn't say, "Every unhappy path is unhappy in its own way."

Debugging tests

A few extra notes about debugging your tests

Setting up vscode to debug tests

  1. Create a new "Mocha Tests" launch configuration
  2. Edit that launch.json configuration so that the args property is bdd instead of tdd
  3. Set your breakpoint after the response comes back and look around

Your launch.json file will include a configuration like this:

{
      "type": "node",
      "request": "launch",
      "name": "Mocha Tests",
      "program": "${workspaceFolder}/node_modules/mocha/bin/_mocha",
      "args": [
        "-u",
        "bdd",  // changed
        "--timeout",
        "999999",
        "--colors",
        "${workspaceFolder}/test"
      ],
      "internalConsoleOptions": "openOnSessionStart",
      "skipFiles": [
        "<node_internals>/**"
      ]
    },

Note: JSON doesn't like comments so be sure to remove the one above.

Debugging tips

Here's the best sequence to use when developing express API server apps in a full stack environment (with a react client at hand):

Tests, then postman, then client.

  1. Work endpoint by endpoint, one at a time. Don't skip around.
  2. Write one test & make it run, using npm test and the vscode debugger.
  3. Repeat that cycle until the API endpoint has all the functionality required.
  4. Use npm start to run the server and use postman to completely verify endpoint functionality
  5. Update both tests and server code to fix any issues and run npm test to verify functionality
  6. Run the server and verify that the react client uses the API endpoint correctly.

If you find an API bug with postman or your react client, it means your test coverage is inadequate.

  1. Update your tests to expose the situation you discovered
  2. Make sure the tests fail (and thus expose the bug), then fix the server code
  3. Reverify with postman
  4. Reverify with your react client.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment