ohif-viewer/docs/latest/contributing/testing.md

146 lines
6.1 KiB
Markdown
Raw Normal View History

2019-08-21 22:20:47 +02:00
# Contributing: Tests
> Testing is an opinionated topic. Here is a rough overview of our testing
> philosiphy. See something you want to discuss or think should be changed? Open
> a PR and let's discuss.
2019-08-22 04:26:02 +02:00
You're an engineer. You know how to write code, and writing tests isn't all that
different. But do you know why we write tests? Do you know when to write one, or
what kind of test to write? How do you know if a test is a _"good"_ test? This
2019-08-22 04:54:00 +02:00
document's goal is to give you the tools you need to make those determinations.
2019-08-22 04:26:02 +02:00
2019-08-22 05:06:30 +02:00
Okay. So why do we write tests? To increase our... **CONFIDENCE**
2019-08-22 04:26:02 +02:00
2019-08-22 05:06:30 +02:00
- If I do a large refactor, does everything still work?
- If I changed some critical piece of code, is it safe to push to production?
2019-08-22 04:26:02 +02:00
2019-08-22 05:06:30 +02:00
Gaining the confidence we need to answer these questions after every change is
costly. Good tests allow us to answer them without manual regression testing.
2019-08-22 05:24:03 +02:00
What and how we choose to test to increase that confidence is nuanced.
2019-08-21 22:20:47 +02:00
## Kinds of Tests
2019-08-21 23:42:33 +02:00
Test's buy us confidence, but not all tests are created equal. Each kind of test
2019-08-22 04:54:00 +02:00
has a different cost to write and maintain. An expensive test is worth it if it
2019-08-22 05:06:30 +02:00
gives us confidence that a payment is processed, but it may not be the best
2019-08-22 04:54:00 +02:00
choice for asserting an element's border color.
2019-08-21 23:42:33 +02:00
2019-08-22 04:54:00 +02:00
| Test Type | Example | Speed | Cost |
| ----------- | ------------------------------------------------------------------------ | ---------------- | ------------------------------------------------------------------------ |
2019-08-22 05:24:03 +02:00
| Static | `addNums(1, '2')` called with `string`, expected `int`. | :rocket: Instant | :money_with_wings: |
| Unit | `addNums(1, 2)` returns expected result `3` | :airplane: Fast | :money_with_wings::money_with_wings: |
2019-08-22 04:54:00 +02:00
| Integration | Clicking "Sign In", navigates to the dashboard (mocked network requests) | :running: Okay | :money_with_wings::money_with_wings::money_with_wings: |
| End-to-end | Clicking "Sign In", navigates to the dashboard (no mocks) | :turtle: Slow | :money_with_wings::money_with_wings::money_with_wings::money_with_wings: |
2019-08-21 22:20:47 +02:00
2019-08-22 05:06:30 +02:00
- :rocket: Speed: How quickly tests run
- :money_with_wings: Cost: Time to write, and to debug when broken (more points
of failure)
2019-08-21 22:20:47 +02:00
### Static Code Analysis
Modern tooling gives us this "for free". It can catch invalid regular
expressions, unused variables, and guarantee we're calling methods/functions
with the expected paramater types.
Example Tooling:
- [ESLint][eslint-rules]
2019-08-22 04:54:00 +02:00
- [TypeScript][typescript-docs] or [Flow][flow-org]
2019-08-21 22:20:47 +02:00
### Unit Tests
2019-08-22 05:24:03 +02:00
The building blocks of our libraries and applications. For these, you'll often
be testing a single function or method. Conceptually, this equates to:
_Pure Function Test:_
- If I call `sum(2, 2)`, I expect the output to be `4`
_Side Effect Test:_
- If I call `resetViewport(viewport)`, I expect `cornerstone.reset` to be called
with `viewport`
2019-08-21 22:20:47 +02:00
2019-08-22 05:24:03 +02:00
#### When to use
2019-08-21 23:42:33 +02:00
2019-08-22 05:24:03 +02:00
Anything that is exposed as public API should have unit tests.
2019-08-21 23:42:33 +02:00
2019-08-22 05:24:03 +02:00
#### When to avoid
2019-08-21 23:42:33 +02:00
2019-08-22 05:24:03 +02:00
You're actually testing implementation details. You're testing implementation
details if:
2019-08-21 23:42:33 +02:00
- Your test does something that the consumer of your code would never do.
- IE. Using a private function
- A refactor can break your tests
2019-08-21 22:20:47 +02:00
### Integration Tests
2019-08-22 05:06:30 +02:00
We write integration tests to gain confidence that several units work together.
Generally, we want to mock as little as possible for these tests. In practice,
this means only mocking network requests.
2019-08-21 22:20:47 +02:00
2019-08-22 05:24:03 +02:00
#### When to use
...
2019-08-21 22:20:47 +02:00
### End-to-End Tests
2019-08-22 02:42:41 +02:00
These are the most expensive tests to write and maintain. Largely because, when
they fail, they have the largest number of potential points of failure. So why
2019-08-22 05:06:30 +02:00
do we write them? Because they also buy us the most confidence.
2019-08-22 02:42:41 +02:00
2019-08-22 05:24:03 +02:00
#### When to use
2019-08-22 02:42:41 +02:00
2019-08-22 04:54:00 +02:00
Mission critical features and functionality, or to cover a large breadth of
functionality until unit tests catch up. Unsure if we should have a test for
2019-08-22 02:42:41 +02:00
feature `X` or scenario `Y`? Open an issue and let's discuss.
2019-08-21 22:20:47 +02:00
2019-08-22 05:24:03 +02:00
## Summary
- Does your test increase confidence?
- Does the test type chosen balance the cost-to-confidence ratio?
2019-08-21 22:20:47 +02:00
## Further Reading
2019-08-22 04:54:00 +02:00
### General
2019-08-21 22:20:47 +02:00
- [Assert(js) Conf 2018 Talks][assert-js-talks]
2019-08-21 23:42:33 +02:00
- [Write tests. Not too many. Mostly integration.][kent-talk] - Kent C. Dodds
- [I see your point, but…][gleb-talk] - Gleb Bahmutov
2019-08-22 04:54:00 +02:00
- [Static vs Unit vs Integration vs E2E Testing][kent-blog] - Kent C. Dodds
2019-08-22 02:42:41 +02:00
(Blog)
2019-08-21 22:20:47 +02:00
2019-08-22 04:54:00 +02:00
### End-to-end Testing w/ Cypress
- [Getting Started](https://docs.cypress.io/guides/overview/why-cypress.html)
- Be sure to check out `Getting Started` and `Core Concepts`
- [Best Practices](https://docs.cypress.io/guides/references/best-practices.html)
- [Example Recipes](https://docs.cypress.io/examples/examples/recipes.html)
2019-08-22 05:25:31 +02:00
## Testing Dorito
[![testing dorito][testing-dorito-img]][testing-dorito]
2019-08-21 22:20:47 +02:00
<!--
Links
-->
<!-- prettier-ignore-start -->
[eslint-rules]: https://eslint.org/docs/rules/
[typescript-docs]: https://www.typescriptlang.org/docs/home.html
2019-08-22 04:54:00 +02:00
[flow-org]: https://flow.org/
2019-08-21 23:42:33 +02:00
<!-- Talks -->
2019-08-21 22:20:47 +02:00
[assert-js-talks]: https://www.youtube.com/playlist?list=PLZ66c9_z3umNSrKSb5cmpxdXZcIPNvKGw
2019-08-21 23:42:33 +02:00
[kent-talk]: https://www.youtube.com/watch?list=PLV5CVI1eNcJgNqzNwcs4UKrlJdhfDjshf
[gleb-talk]: https://www.youtube.com/watch?v=5FnalKRjpZk
2019-08-22 02:42:41 +02:00
[kent-blog]: https://kentcdodds.com/blog/unit-vs-integration-vs-e2e-tests
2019-08-21 23:42:33 +02:00
<!-- Images -->
2019-08-21 22:20:47 +02:00
[testing-trophy]: https://twitter.com/kentcdodds/status/960723172591992832?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E960723172591992832&ref_url=https%3A%2F%2Fkentcdodds.com%2Fblog%2Fwrite-tests
[aaron-square]: https://twitter.com/Carofine247/status/966727489274961920
[gleb-pyramid]: https://twitter.com/Carofine247/status/966764532046684160/photo/3
[testing-pyramid]: https://dojo.ministryoftesting.com/dojo/lessons/the-mobile-test-pyramid
[testing-dorito]: https://twitter.com/denvercoder/status/960752578198843392
2019-08-22 05:24:03 +02:00
[testing-dorito-img]: https://pbs.twimg.com/media/DVVHXycUMAAcN-F?format=jpg&name=4096x4096
2019-08-21 22:20:47 +02:00
<!-- prettier-ignore-end -->