MoreQARespect

16 ms·

181.
by MoreQARespect 3y ago
Dependency inversion with the aim of writing unit tests is helpful for logic or calculation heavy chunks of code but for everything else it actually makes the code less maintainable. It balloons the size of the code base and as a reward you
182.
by MoreQARespect 3y ago
Like this https://github.com/hitchdev/hitchstory ?
183.
by MoreQARespect 3y ago
What you call them isn't really important. "Unit tests with mocks" or whatever they are still suck.
184.
by MoreQARespect 3y ago
Yes. For example, most CRUD apps are like this almost by definition. It's more common for domain logic to be fairly simple and smeared across multiple systems and languages, though - e.g. some is in SQL, some is in a separate microse
185.
by MoreQARespect 3y ago
Clean functions with limited dependencies which encode non-trivial domain logic are indeed well served by unit tests - even if theyre a bit imperative. But, outside of contrived interview scenarios this type of code is actually somewhat nic
186.
by MoreQARespect 3y ago
I think you miss the point. With a lot of code once you've mocked out all the dependencies you're not left with anything to test apart from assert derp == derp.
187.
by MoreQARespect 3y ago
It can be fairly quick with tools like mitmproxy.
188.
by MoreQARespect 3y ago
Unit tests help in a very specific circumstance - when you're testing complex calculations or logical code with simple inputs or outputs. Some projects have almost zero code like this. In all other situations they suck. When they fail
189.
by MoreQARespect 3y ago
It's so tedious seeing how many people don't get this. Enshittification following a buyout is practically a rite of passage.
190.
by MoreQARespect 3y ago
How does it know if a selector is going to be reliable?
191.
by MoreQARespect 3y ago
The compose stack tests (when engineered right), are the only ones which can reliably reproduce and test almost any bug or feature reliably. In 2018 I could understand the aversion to them given how unbearably slow and flaky they could be b
192.
by MoreQARespect 3y ago
>This often involves making the dependencies you inject during testing some more complete simulations of real implementations. Takes more up front effort to implement them, but can often be re-used between many tests. At higher levels, t
193.
by MoreQARespect 3y ago
Where not everything is precisely defined but "you know the right outcome when you see it" is where I think snapshot test driven development really shines: https://hitchdev.com/hitchstory/approach/snapsho
194.
by MoreQARespect 3y ago
I have this too, but with a specification-by-example integration test with a brief explanation that autogenerates readable "step by step" markdown how-to docs. The idea being that new features should be fully tested and clearly do
195.
by MoreQARespect 3y ago
Sounds like snapshot test driven development would work well in that case though: https://hitchdev.com/hitchstory/approach/snapshot-test-drive... Write a scenario that uses a new water shader - eyeball it - if it&
196.
by MoreQARespect 3y ago
I've seen it done properly with unit tests on algorithmic or decision making code (parsers, calculators, complex, deterministic thinking code). I've seen it done properly with integration tests on integration code (CRUD, messaging
197.
by MoreQARespect 3y ago
>It's simple enough, as you say it's mostly templating, but the hardest part I found is maintaining dependencies. I needed to keep all dependencies up-to-date, which was a big amount of manual work. For something like React-nat
198.
by MoreQARespect 3y ago
It does depend on the nature of the code. My rule of thumb is integration code -> integration tests work better. Algorithmic/calculation code -> unit tests work better. A debugger attached to an end to end test probably better if
199.
by MoreQARespect 3y ago
They're called mimetic tests: https://hitchdev.com/tropes/mimetic-tests/ For self contained algorithmic or calculation code with simple inputs and outputs, TDD with unit tests really shines. If your app is mo
200.
by MoreQARespect 3y ago
End to end tests by definition are more loosely coupled. They are better as executable documentation - mapping to actual user flows and able to generate docs (videos, screenshots, etc.). They're slower, but it's easy enough to par
201.
by MoreQARespect 3y ago
I followed this approach once and ended up abandoning a week's worth of work because it was just far too slow (hours vs < 1 minute) when running on large quantities of data. >This leaves more room for error and makes our logic ha
202.
by MoreQARespect 3y ago
It is fundamental but it's in constant tension with other principles - e.g. cohesion and coupling. I'm pretty sure all of the most fundamental principles of good code are in tension with each other.
203.
by MoreQARespect 3y ago
This is kind of how I felt about the S in single responsibility of SOLID too. I wonder if there are any principles out there which are actually objective/measurable.