22 Matching Annotations
- Jul 2022
-
github.com github.com
-
Interestingly, Rails doesn't see this in their test suite because they set this value during setup:
-
- Dec 2021
-
www.chris-granger.com www.chris-granger.com
-
Most of the descriptions I’ve seen focus on mechanisms - block chains, smart contracts, tokens, etc - but I would argue those are implementation details and some are much more likely to succeed than others. (E.g. I think using private keys for authentication/authorization is obviously better if you can get over the UX hump - SSH has shown us that for decades.)
Most descriptions of Web3 focus on mechanisms — blockchains, smart contracts, etc — but those are implementation details.
-
- 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.
-
- Jun 2021
-
www.mutuallyhuman.com www.mutuallyhuman.com
-
For me the diagrams make it easier to talk about what the tests do without getting bogged down by how they do it.
Tags
- communication: use the right level of detail
- focus on what it should do, not on how it should do it (implementation details; software design)
- too detailed
- communication: focus on what is important
- describe the what without getting bogged down by how (implementation details; too detailed)
- communication: effective communication
Annotators
URL
-
-
docs.gitlab.com docs.gitlab.com
-
Do not test the internal implementation of the child components:
-
- Mar 2021
-
trailblazer.to trailblazer.to
-
There’s no need to test controllers, models, service objects, etc. in isolation
Tags
- isolation (programming)
- testing: tests should resemble the way your software is used
- testing: avoid unnecessarily testing things in too much isolation, in a different way than the code is actually used (should match production)
- unnecessary
- testing: avoid testing implementation details
Annotators
URL
-
- Feb 2021
-
github.com github.com
-
While Trailblazer offers you abstraction layers for all aspects of Ruby On Rails, it does not missionize you. Wherever you want, you may fall back to the "Rails Way" with fat models, monolithic controllers, global helpers, etc. This is not a bad thing, but allows you to step-wise introduce Trailblazer's encapsulation in your app without having to rewrite it.
Tags
- allowing developer/user to pick and choose which pieces to use (allowing use with competing libraries; not being too opinionated; not forcing recommended way on you)
- Trailblazer
- making changes / switching/migrating gradually/incrementally/step-wise/iteratively
- abstractions
- leaving the details of implementation/integration up to you
- freedom of user to override specific decision of an authority/vendor (software)
- focus on what it should do, not on how it should do it (implementation details; software design)
- focus on concepts/design/structure instead of specific/concrete technology/implementation
- newer/better ways of doing things
- rails: the Rails way
Annotators
URL
-
-
softwareengineering.stackexchange.com softwareengineering.stackexchange.com
-
The more important point comes from a program design perspective. Here, "programming to an interface" means focusing your design on what the code is doing, not how it does it. This is a vital distinction that pushes your design towards correctness and flexibility.
-
- Dec 2020
-
github.com github.com
-
I don't think this is what really matters at the end, since whatever is the implementation the goal should be to provide a library that people actually like to use.
-
- Sep 2020
-
github.com github.com
-
The feature is highly likely to be implemented, the API and implementation are the only real topics of discussion right now.
-
- Jul 2020
-
rails.lighthouseapp.com rails.lighthouseapp.com
-
It would be nice if the tests weren't so implementation specific, but rather tested the essence of the functionality. I tried to make them less brittle but failed. To that end, re-writing all the tests in rspec would be (IMHO) a brilliant improvement and pave the way for better tests in the future and more flexibility in implementation.
-
- Apr 2020
-
github.com github.com
-
Devise-Two-Factor only worries about the backend, leaving the details of the integration up to you. This means that you're responsible for building the UI that drives the gem. While there is an example Rails application included in the gem, it is important to remember that this gem is intentionally very open-ended, and you should build a user experience which fits your individual application.
-
- Nov 2019
-
kentcdodds.com kentcdodds.com
-
it doesn't even render in-file components. For example, the <Fade /> component we have above is an implementation detail of the <HiddenMessage /> component, but because we're shallow rendering <Fade /> isn't rendered so changes to that component could break our application but not our test. That's a major issue in my mind and is evidence to me that we're testing implementation details.
-
The reason this kind of test fails those considerations is because it's testing irrelevant implementation details. The user doesn't care one bit what things are called. In fact, that test doesn't even verify that the message is hidden properly when the show state is false or shown when the show state is true. So not only does the test not do a great job keeping us safe from breakages, it's also flakey and doesn't actually test the reason the component exists in the first place.
-
I could rename toggle to handleButtonClick (and update the corresponding onClick reference). My test breaks despite this being a refactor.
-
I could mistakenly set onClick of the button to this.tgogle instead of this.toggle. My test continues to work, but my component is broken.
-
Will this test break when there's a mistake that would break the component in production?Will this test continue to work when there's a fully backward compatible refactor of the component?
-
-
kentcdodds.com kentcdodds.com
-
-
Why is testing implementation details bad?There are two distinct reasons that it's important to avoid testing implementation details. Tests which test implementation details:Can break when you refactor application code. False negativesMay not fail when you break application code. False positives
-
-
kentcdodds.com kentcdodds.com
-
But far too often, I see tests which are testing implementation details (read this before continuing if you haven't already). When you do this, you introduce a third user. The developer user and the end user are really all that matters for this component. So long as it serves those two, then it has a reason to exist. And when you're maintaining the component you need to keep those two users in mind to make sure that if you break the contract with them, you do something to handle that change.But as soon as you start testing things which your developer user and end user don't know or care about (implementation details), you add a third testing user, you're now having to keep that third user in your head and make sure you account for changes that affect the testing user as well.
-
-
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.
-
- Jan 2014
-
blogs.msdn.com blogs.msdn.com
-
I regret that the documentation does not focus on what is most relevant; by focusing on a largely irrelevant implementation detail, we enlarge the importance of that implementation detail and obscure the importance of what makes a value type semantically useful. I dearly wish that all those articles explaining what “the stack” is would instead spend time explaining what exactly “copied by value” means and how misunderstanding or misusing “copy by value” can cause bugs.
Documentation should focus on semantically useful descriptions; another accompanying document (or annotation) can provide relevant implementation details upon request, but that deeper level of detail should be left out by default to avoid enlarging the importance of less relevant things.
-