The ONLY REASON To Unit Test
Unit testing is an essential practice in software development that involves testing individual units or components of a program to ensure they work correctly. While there are many benefits to unit testing, there is one reason that stands above all others as the most important: to catch bugs early.
By writing unit tests for your code, you can identify and fix bugs before they have a chance to cause larger issues in your application. This can save you time and effort in the long run, as it is much easier to fix a bug at the unit level than it is to track down and fix a bug that has been caused by a failure in multiple components.
Unit testing also helps to improve the overall quality of your code. By writing tests that check the functionality of individual units, you can ensure that your code is working as intended and that changes to one part of the codebase do not inadvertently break another part. This can help to prevent regressions and ensure that your code is well-maintained and scalable.
Additionally, unit testing can help to improve the design of your code. By writing tests first, you are forced to think about how your code will be used and how it should behave in different scenarios. This can lead to cleaner, more modular code that is easier to maintain and extend in the future.
In conclusion, the only reason to unit test is to catch bugs early. By writing tests for your code, you can identify and fix issues before they become larger problems, improve the overall quality of your code, and create a more maintainable and scalable codebase. Unit testing may take some extra time and effort upfront, but the benefits far outweigh the costs in the long run.
Thumbs up for "beer is the Canadian cocaine"
I think it depends a lot of what you are building.
If you are building a frontend application or a backend application or a library are totally different ways to build.
In libraries and backend, with framework agnostic code, TDD works great.
In the frontend, it is a total different world.
In the frontend, E2E tests are more interesting than unit tests.
Unit tests are useful for small parts in the frontend, with specific functions that isn't frontend specific.
If you do something with the DOM, what I think are side effects, it is difficult to unit test.
I stopped listening on "a heavily tested codebase is heavily tested because the code is shit".
A well tested codebase is what makes code robust and well maintained.
You won't catch many of the bugs that occur when upgrading your packages or when other devs change something in your code.
It's been a lifesaver for me and you sir have no idea what you're talking about.
These are end-to-end tests. They are using the same entry points the client would
Good written tests are a boilerplate for new engineers/developers to understand the exact context/usage of a particular use of code. "tests make it much less likely, that you're going to change the code underneath them" – wrong, tests with good coverage make you much more confident that changing code won't break the application…..
"If tests are preventing fast movement, they are also hurting your ability to fix things when things go wrong"" – again, wrong – something goes wrong in production without tests, you'll be wasting time finding/debugging/fixing the bug a test would have caught originally….
Types defines a theory, unit tests define the reality, simulate the runtime.
this is something i say a lot. you have a collection of tools. unit tests are one of those tools. every tool is for a specific job. you cannot use them for everything. you shouldnt use a hammer to try and drive in a screw. you shouldnt use a fork with soup. there are a lot of tools at your disposal as a programmer and i think we are still kind of in a wild west period where a lot of people, including senior developers with decades of experience, dont actually fully understand the right and wrong places to use all of these tools that are available. there's so, so very many, and so, so very many conflicting opinions on all of them that there's just no way it's possible for anyone to have a full understanding of everything and all of the best use cases for all of it. and what anyone needs to do as a programmer is question what and why other programmers are telling you are the right and wrong things to do or use and decide for yourself if their arguments work for you (or your team) or not. for a lot of people, unit tests DO work for them, and very well, but for others, not so much.
It's simple, you just don't test the goddamn implementation, they're called Specs for a reason, you're supposed to be describing the underlying specification of the thing, not how it accomplishes this at the moment. But yes because most devs learned to Unit Test in existing codebases, most devs get this wrong and get used to testing implementations
Unit tests for typescript/react apps are a bit heavy-handed yeah.
Ive had changes pushed to production where i work that, if we had proper tests (which ive been pushing to get people to focus on…) would have been caught easily, but werent because so many things ran through the same internals (especially around auth and events) that changing anything there always risked breaking something because so much relied on those few sections of the code. When someone makes an optimisation for one case and it breaks another pattern they didnt even know existed, you're going to have a bad time if you aren't running unit tests.
honestly it is wild that a popular tech youtuber is actively recommending against testing for most projects. If every path in your code has basically zero overlap with other parts testing may be less useful, but the more important certain parts of the codebase become, the more important it becomes to make sure that those parts don't start breaking when you change something
Good luck rely on TS as test coverage strategy for I/O and algorithms. xD This argument always amuses me. I would not listen to a engineer who almost solely work on frontend, he has not seen many sides of software engineering based on the weak scenarios and arguments mentioned as weakness of unit tests. The main difference is that Theo does not have same wide engineering experience (trial and error) like a experienced system engineer like Prime, who clearly has been working low and high. Sadly many juniors will listen to this BS because all over YouTube – if popular it must be high quality right?
Yikes, couldn't agree less.
"Amazing experience uploading files", now that is what keeps me up at night and motivates me everyday 🤣🤣🤣🤣🤣
nice shit!
I know where not to go on YouTube.
I think you're in your honeymoon phase for a startup where you are encouraged to deliver everything as soon as possible if it works good enough. When project matures and you are to bound to contracts including QoS terms, you cannot afford to just deploy to prod and rollback once your client finds a bug. You get fined for it. At that point, you either take the time and money to improve coverage or you hope to sell the whole product to someone else who then outsources it to the cheapest place possible while trying to squeeze as much money as possible before the codebase crashes and burns from the technical debt. You can imagine a scenario where a project performs tens of thousands of transactions before you notice it in production. At that point, you can only pray nothing bad happened and you are the first one to discover the bug in time for resolving the issue without lasting consequences. Or you're already cooked if legally bound to disclose it like with HIPAA or GDPR.
Also, TDD is great if you write libraries where you force yourself to use your own product right from the beginning. If an interface feels awkward, you change it for the sake of you and your users right when it starts to be/feel messy. This helps you to catch mistakes in organization of code and makes your interfaces more friendly to use which is one of the most important things for a library to succeed. After that, your well-defined interface is frozen till next major release and your tests are living documentation following the code to your customers.
The last things is that having proper test suite helps developers with going through the business logic without having to debug everything till it becomes clear. It speeds up onboarding without the need to have everything explained by someone more senior.
I hate the discussion about unit tests being good or bad. They are simply tools to be applied for the right job. The whole discussion is like having to argue over which one is better – shovel or pickaxe. Well, it depends xD
"Add tests when they solve the problems that only tests can resolve."
Yeah, I agree with this. I’ve just come off a code base with 100% unit test coverage – the code did almost nothing yet somehow broke all the time in the real world.
I think I see this concrete-over-bad-code approach when there is a lot of mutation that isnt isolated to where it’s needed.
If you have your mutations isolated testing the io on that part can cover almost all cases usually in a few tests.
The problem with testing is that someone should actually test your tests
Unit tests for regressions