13 Matching Annotations
- Aug 2024
-
github.com github.com
-
This is the most simulative version of a controller. It will try and mimic real user behaviour. It's the recommended version to use when the goal of the load-test is finding out how many concurrently active users the target instance supports.
-
- Nov 2021
-
www.varvet.com www.varvet.com
-
I am firmly convinced that asserting on the state of the interface is in every way superior to asserting on the state of your model objects in a full-stack test.
-
- Sep 2021
-
www.npmjs.com www.npmjs.com
-
The more your tests resemble the way your software is used, the more confidence they can give you.
-
- Jun 2021
-
docs.gitlab.com docs.gitlab.com
-
targeting what the user actually sees
-
The most important guideline to give is the following: Write clean unit tests if there is actual value in testing a complex piece of logic in isolation to prevent it from breaking in the future Otherwise, try to write your specs as close to the user’s flow as possible
-
It’s better to test a component in the way the user interacts with it: checking the rendered template.
-
- Mar 2021
-
trailblazer.to trailblazer.to
-
There’s no need to test controllers, models, service objects, etc. in isolation
-
Run the complete unit with a certain input set, and test the side-effects. This differs to the Rails Way™ testing style, where smaller units of code, such as a specific validation or a callback, are tested in complete isolation. While that might look tempting and clean, it will create a test environment that is not identical to what happens in production.
Tags
- testing: philosohy of testing
- testing: tests should resemble the way your software is used
- unnecessary
- testing: avoid unnecessarily testing things in too much isolation, in a different way than the code is actually used (should match production)
- rails: the Rails way
- the Trailblazer way
- testing: avoid testing implementation details
- isolation (programming)
Annotators
URL
-
- Nov 2019
-
kentcdodds.com kentcdodds.com
-
"The more your tests resemble the way your software is used, the more confidence they can give you. "
-
-
testing-library.com testing-library.com
-
You want to write maintainable tests for your React components. As a part of this goal, you want your tests to avoid including implementation details of your components and rather focus on making your tests give you the confidence for which they are intended. As part of this, you want your testbase to be maintainable in the long run so refactors of your components (changes to implementation but not functionality) don't break your tests and slow you and your team down.
-
We try to only expose methods and utilities that encourage you to write tests that closely resemble how your web pages are used.
-
The more your tests resemble the way your software is used, the more confidence they can give you.
-
Most of the damaging features have to do with encouraging testing implementation details. Primarily, these are shallow rendering, APIs which allow selecting rendered elements by component constructors, and APIs which allow you to get and interact with component instances (and their state/properties) (most of enzyme's wrapper APIs allow this).
-