Skip to content

Instantly share code, notes, and snippets.

@leahgarrett

leahgarrett/testing-overview.md Secret

Created July 2, 2019 00:05
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save leahgarrett/f3b991587aafff37afe20a30c050fa6d to your computer and use it in GitHub Desktop.
Save leahgarrett/f3b991587aafff37afe20a30c050fa6d to your computer and use it in GitHub Desktop.
Download ZIP
Testing Overview
Raw
testing-overview.md

Testing React


Thoughts on Testing React Components
https://www.youtube.com/watch?v=gJMYMnyA7ZE

  • Testing is all about confidence. You want to have confidence that your tests are testing your app. For front-end tests, you want to have confidence that your tests are going to simulate the end user really well.

  • Mocking all dependencies => you can ship bugs if one of the dependant component breaks

  • You could mock an animation library.

  • Shallow rendering can cause the same issue.

  • Snapshots show implementation details.

  • Recommend to use render and only use mounting if you need to interact with the component.

What makes a good test

  • runs fast
  • doesn't break often
  • easy to read / understand
  • catches bugs
  • good coverage to effort ratio

Types of tests

  • End-to-End tests
    Manual testing, screen automation

  • Integration tests
    Testing multiple functions or components

  • Unit tests
    Testing one function or component


End-to-end tests that focus on real user scenarios sound like a great idea in theory. But not in practice: https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html

UnitEnd-toEnd
Fast


Reliable



Isolates Failures


Simulates a Real User


Write tests with different granularity. The more high-level you get the fewer tests you should have.

https://2.bp.blogspot.com/-YTzv_O4TnkA/VTgexlumP1I/AAAAAAAAAJ8/57-rnwyvP6g/s1600/image02.png

 The bulk of your tests are unit tests at the bottom of the pyramid. As you move up the pyramid, your tests gets larger, but at the same time the number of tests (the width of your pyramid) gets smaller. As a good first guess, Google often suggests a 70/20/10 split: 70% unit tests, 20% integration tests, and 10% end-to-end tests. The exact mix will be different for each team, but in general, it should retain that pyramid shape.

Test break-down on example apps

Three examples of different approaches to testing.


Start-up - conversational UI

In this team we had a dedicated QA that wrote some End to End tests. We used the End to end test harness when developing so we could quickly get the the page we were working on eg: page 15.

TDD and pair programming was used all the time. The test suite was huge and took over 45 minutes to run. The tests had to pass before submitting a Pull Request.

Test type Proportion of total Description
End to end 20% Three types
  • QA staff built and maintained some E2E tests using a QA tools
  • Developer built E2E tests using Selenium. These were difficult to debug and took a lot of time to fix
  • QA and Developer manual testing, including for cross device
Integration 20% Only a small amount of integration tests as we had coverage in the other areas.
Unit 60% We used TDD and had great code coverage with Unit tests.

Start-up - complicated data structure and UI

Focusing integration tests on reporting meant that this app had good test coverage with great ROI on tests.

Test type Proportion of total Description
End to end 20% Manual only. We had a PM that also did QA tasks as well as users working on UAT.
Integration 40% A large portion of automated tests were testing the reporting system. These gave good coverage of the calculation system.
Unit 40% Not all parts were easy to test

Internal financial forecasting and reporting application

The UI for this internal app was constantly changing. It was used as experimentation for developers. The main priority was accuracy of the data. Tests were mostly around the data and formula. There was limited coverage on the UI.

Test type Proportion of total Description
End to end 60% Most testing on this project was manual testing by Dev team.
Integration 20% The data source was buggy so a test harness was written to help debug.
Unit 20% Not many tests or much coverage.

Unit tests

What not to test?
Don't test trivial code. You won't gain anything from testing simple getters or setters or other trivial implementations (e.g. without any conditional logic)

Mocking
Unit tests should test the unit under test not dependencies. To remove dependencies we use mocking. There are packages that provide mocks for function calls, database, and API calls.

What makes a good test

  • runs fast
  • doesn't break often
  • easy to read / understand
  • catches bugs
  • good coverage to effort ratio

Further Resources

https://martinfowler.com/articles/practical-test-pyramid.html

Delightful JavaScript Testing with Jest
https://www.youtube.com/watch?v=cAKYQpTC7MA&t=445s

Good articles on TDD
https://medium.com/javascript-scene/tdd-the-rite-way-53c9b46f45e3
https://www.freecodecamp.org/news/a-quick-introduction-to-test-driven-development-with-jest-cac71cb94e50/

https://www.pluralsight.com/guides/introduction-to-test-driven-development-in-javascript

Justin Searls – Please don’t mock me
https://www.youtube.com/watch?v=Af4M8GMoxi4

Testing React
https://www.freecodecamp.org/news/the-right-way-to-test-react-components-548a4736ab22/

Simple example
https://github.com/leveluptuts/Level-Up-JavaScript-Testing-101

Mocking
https://robdodson.me/mocking-requests-with-mocha-chai-and-sinon/
https://www.leighhalliday.com/mocking-axios-in-jest-testing-async-functions

https://medium.com/@rickhanlonii/understanding-jest-mocks-f0046c68e53c

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