4 ms·
No they're not. Unit tests are only overrated when you're hacking some shit together rather than doing forward engineering. No one does proper forward engineeri
by baz00 3y ago
No they're not. Unit tests are only overrated when you're hacking some shit together rather than doing forward engineering. No one does proper forward engineering these days which is why it doesn't seem applicable. If you have thought about the problem first you know the constraints and they match 1:1 with the test cases, then you build it, then it works. You can't test or understand side effects for everything at the boundary of a system from experience.
The biggest sin of the whole IT sector at the moment is lack of quality and this thinking drives it further towards hell.
Do less, do it slower but do a better job please.
- kriro 3y agoThis POV is debateable (but I sympathize strongly with your sentiment). If quick but shitty allows me to capture a lot of value then quick and shitty might be the way to go. Yes there are major downsides but especially in a "scaleup" setting they are often dwarfed by the upsides of shitty but fast. As an engineer, I hate it because I want to build perfect and long term all the time but in many cases you can't really argue with the monetary benefits of knowingly delivering underwhelming things that get the job done well enough for now (even knoing deep in your heart that many of the issues might never be fixed). A good example is security. Sometimes it's righ to ship stuff with security issues that you know exist and might even be 10+ million dollar issues if discovered quickly if for example fixing thoses issues might interfere with adoption because they make user onboarding slightly more annoying.
- louthy 3y agoWhilst the core message of your comment I agree with, unit tests are not the only way to achieve this; but there's often blanket statements made about 100% code coverage, and all that nonsense - which really just fetishizes unit testing rather than critically thinking about the goal of a unit-test. For example, better use of types to make sure applications physically can't get into a bad state will always have better returns in terms of velocity and correctness than checking after the fact with unit-tests. It has the additional benefit of being compositional, unlike unit tests. This can be done for data representation but also transitions of state, which is all of software engineering outside of IO.
- MoreQARespect 3y agoIronically the goals of unit tests are almost always better served by higher level integration tests - tests that actually call APIs, put data in the database and retrieve it, etc.