We Finally Agree On Unit Tests
Вставка
- Опубліковано 8 вер 2024
- Prime may have kickstarted my channel with our unit test disagreements, but ultimately, seems like we agree.
ORIGINAL VIDEO: • Lets Chat About Unit T...
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏
I like unit tests because it stops some idiot on my team from doing something stupid and deleting necessary code accidentally. The number of times unit tests have stopped people from deleting important code is actually quite astonishing lol.
one could argue code reviews are better for this
@@MaxFung unit tests are a faster and more reliable way of ensuring this does not happen. Because most people review for style, maybe local logic they can see in the PR itself, and very rarely overall logic.
(in frontend), unit tests basically help you make sure you didn't change/delete the wrong thing. They are very simple, and usually do tests implementation details (something that is not possible to do in react anymore after functional components, sadly)
the more helpful tests are integration tests where you simulate user's behaviour and then check the html output. Which is like unit tests of other fields.
I had a case where they commented the test that failed after their change
@@MaxFung LGTM!
For what it's worth, a dynamic programming algorithm is a specific kind of algorithm that implements the divide-and-conquer approach, not literally an algorithm that it is dynamic in the sense that it is "likely to change"
I don't think you'd describe dynamic programming as "divide and conquer". Dynamic programming is mostly bottom-up which allows "small instances" to be solved only once and solutions to larger instances to be built up from them. Your larger point still stands, of course.
Dynamic programming is about reflections and metaprogramming when the program can dynamically modify its own code 😅
Not that algorithmic crap they overuse on shitty interviews
He's right and both you guys are wrong.
en.wikipedia.org/wiki/Dynamic_programming
It's about looking at a problem, breaking it down into sub-problems, and solving each one optimally. This also may require recursively breaking down the sub-problems into further sub-problems which means this is actually a top-down and not bottom-up approach.
And the comment on metaprogramming? What drugs are you on? What the fuck was that?
@@cvoges12 Did you even read the section on Computer Science? If there are overlapping sub-problems, which is the only case which I have ever seen called Dynamic Programming (your article also agrees with me on that), then a bottom-up approach is better.
@@TheTim466 Just b/c you should do dynamic programming in a bottom up way doesn't mean that's what dynamic programming means. And no, the article I sent doesn't say that it *is* bottom-up. What did you do? Ctrl+f for bottom-up and post "ah-ha, I have smote thee!"
I like unit tests at three boundaries:
1) catching changes in third party deps
2) important algorithms or mechanism that need to be verified and documented at bare-bones level.
3) Catching I/O impedance mismatch (not including integration testing, but could overlap)
YES and I believe these two are giving bad advice on testing.
I like to call my tests module tests, where each module has a facade to talk to outside components. Module tests are are written against the interface of this facade and are agnostic about internal classes/functions/fields.
Now you're free to change the implementation details that sits behind the facade, such as classes, fields, functions, without having to touch the tests.
Personally, I also like to do unit tests for specific systems that require certain date-handling logic, or calculating things based on formulas. It's nothing more than a big block of input -> output values and a single function call, but when the client comes with an edge case, I can add it to the list and make sure it works, or will work after fixing the bug.
I LOVE when unit tests can be expressed as input/output data. It's so nice.
@@reed6514 that is how all tests should be. If your tests can't work like that then your code isn't written in a testable manner, and probably needs to be refactored to be more testable.
i find asking for unit tests from juniors or outsourced engineers to be useful as it causes them to have to think about and review their own code before they raise the PR. It forces them to learn how to write simple code that is easy to test. Once they progress, then the training wheels can come off.
"Tests are a slightly better version of a code comment that guides you in the right direction" 10:47
This is a key takeaway for me. Our team has been struggling with the why for a long time. Code coverage and feature correctness are a nuisance and a solved problem respectively, so unit testing everything has been a hard sell.
Thanks Theo and Prime for helping me understand some real reasons to do unit tests.
Edit: 18:22 is also a huge takeaway for me as well. I've never really thought about how much time ive spent manually testing a feature when a unit test could've been doing that for me the whole time. It shortens the feedback cycle so much.
Without having any tests how would you ever safely know that the code you made is still working if you do changes to it. The more complex the code is the more tests it requires. I wouldn't sleep well at night doing changes to a code base without knowing if those changes actually work. If the code as many variants on the input then one can use property based tests to generate all the possible cases that it needs to cover doing that makes me feel way more confident that the code is doing what it supposed to be doing. People who say code coverage is important is just half right in my opinion having anything above 80% is just a waste of effort since the last percent is just edge cases that nearly never happens also code coverage doesn't tell you anything about the quality of the tests but it can give you an indicator that you have to few tests if the value is really low.
Code coverage was the issue at 6:50, not unit testing, code coverage is not a valid metric for anything. It's just an indicative that no tests have reached a line of code, so perhaps you could add a new test to make it 100%, but only if if suits your needs.
😂 ain’t none of you worked on a dynamic programming problem at work in the last 6 months. Solving leet code isn’t work. The “hardest” algorithm I’ve ever needed to implement in the last 10 years of web dev work was recursively traversing a tree. Do y’all work at universities or something?
The problem with unit tests is that I used to think you need to write tests for every unit eg. every function etc. However, we can write a series of test sfor the main function that uses a bunch of functions that are not even accessible outside the file, and through testing behaviour, still get 100% code coverage. Doing this recently has meant I can easily refactor all the private functions or even the main function with ease. In the past, I'd have a test for every function instead of just testing the main one. That made writing tests slow and painful.
In fairness, if I did write a test for an innermost function due to complexity, either it should be another module with its own behaviours or I should just throw those tests away and just have tests through the main function.
I think a lot of people have a wrong definition of what is a unit because there is no standard definition, and often no one even tries to define it. I would say a unit is defined by a public point of entry into your software. Ultimately, those points of entries are the only things that matter. Everything else is just a black box to the end user. We should be treating our tests like an end user, they should only care about what they can see publicly.
@@evancombs5159 Yeah I agree. The definition hasn't been solidified, which makes me wonder who initially said it . A unit is defined by a public point of entry is a good way to describe it.
Why is no one ever discussing the risk of scaring away customers if you allow for and count on fixing bugs in production on a regular basis? Like, my sense of pride in my work hurt when I have caused friction for our users, but I don't actually have any stats for how critical bugs have to be for the user to stop using what we build. It just seems like a no brainer most of the time to try to not release buggy stuff.
I personally find buggy apps and services painful to use (from entertainment to banking), I don't really think getting new features fast makes up for it because that just adds new friction faster along with them. But I might be in the minority.
Yeah good point No one is going to be hurt if Theos start up releases a breaking bug vs companies that deal with critical business infrastructure and millions lost with breaking bugs. If inconvenient for the developer prevents this but is slower it is a win in the end.
This. 100%.
I hard-line disagree that unit-tests are not supposed to be a safety net. Unit-tests are an early warning-signal and a team should treat them as such.
They show that the expected pre- or post-conditions of our code have been violated and that means we need to negate that.
Whether that means we adjust our implementation (true positive), make the test less strict (false positive), or the team sits down to talk about the design of the system because our implementations are too tightly coupled (structural issue).
Regardless of what the outcome of looking at the early warning-signal is, it is infinitely better than not having an early warning-signal and having to react to a user reporting a broken application/library. Since that will be far more damaging, both in costs associated to fix the issue and the reputational damages you'd incur.
Can you test everything? No, some edge-cases are just not feasible to write tests for, but 80% coverage is doable for most projects and if you can't reach that you've got other issues you need to look at.
When I write prototypes, I write a minimal amount of tests to guide my thinking since I'm scrapping the entire thing anyway.
"if you're just building a little website to do something", we can't all work at Netflix Prime!! 😂
True. I like Prime and think he makes some good content but he's also kind of an elitist prick. Probably 95% of devs are doing some kind of web app or extending and maintaining an ERP or CRM system for a non-tech company. He definitely looks down on that.
This is clearly a UI/CRUD/non-essential-service vs engineering perspective. Just be glad that none of the "tests are bad" people would be allowed to work in aerospace or medical systems. Some systems need to work, every time, or people die. "Your layout looks terrible" is not the only kind of problem developers are solving.
I do unit-tests for complex problems I can't hold in my head anymore. We have this query-builder-class that abstracts sql away. It was done as an abstraction as the requirement to switch databases underneath it, is a real possibility and I don't want to rewrite the whole thing, just the transformation layer. This is a place I do unittest quiet heavily. Reason being that it's rather complex and some patterns are really niche. I do not want to worry about them when I implement a new feature or a change. I do not want to be in a position where I push something only to find out 3 weeks later that that one specific query broke due to it. So thats a reason to invest the time to make sure complexity does not break. It kinda is what prime said, you have a simple input, (a builder pattern) and a simple output (A SQL-String with an psql oder mysql dialect), but what happens in between is a bit more complex.
The problem arises when we start to test if 1+1 really does equals 2. If it didn't we'd have a rather different problem.
You might occassionally want to test if 1+1=2, such as if you're writing a programming language or engineering a cpu. But yeah, your point is solid & that's. Very different problem lol.
It's a blessing to be a Clojure engineer with a brilliant REPL-driven development experience, which allows you to write-and-test things "on the go", in one place, and consider adding test coverage later. And, yeah, tests for UI only make sense as end-to-end scenarios anyway, until you're building on top of some reasonably complex abstractions system for UI components, which does not hold true for most of web projects I saw in the wild or worked on so far.
I dont fully understand either take. For me, if I write a function that supposed to do something, I write a test to make sure that it does. I really cant see an argument for not doing that. And it's not writing a unit test for the sake of writing a unit test. It's writing a test because I said this function is supposed to do this thing and I need to make sure that it does.
I get what you’re saying but my default is the opposite of yours: a lot of the functions I write in JS are very simple, take capitalization as an example. These are usually functions that are easily spotted during the e2e tests and easily debugged.
Theoretically speaking, a unit test would be better but all code is something you’ll have to maintain. This is doubly the case for unit tests. The examples given in the video are something I’ve seen at every single employer I’ve worked at in one way or another.
When you're saying "unit tests don't make it easier to refactor", you're actually disagreeing with what the word "refactor" means. Refactoring code means you end up with equivalently-behaving code when you're done. You said you greatly simplified the codebase. The behavior of code is defined by the signatures of its functions (or in an OOP codebase, the API of its classes). You're referring to the end-user experience when you say "refactor" which is different than what the software engineering practice of refactoring refers to and what unit tests make it easier to do. Unit tests help enforce invariants on the behavior (the output for a given input) of your code and that, obviously, makes it easier to refactor (i.e. to replace the implementation with an equivalently-behaving alternative).
I agree. I think Theo is totally wrong on this take. Refactor should mean “I changed the underlying code but this function or set of functions behaves identical to how it behaved before”. And in that sense all your tests should stay green if you actually refactored. If they don’t it could be an indicator of poor abstractions and tightly coupled code.
Exactly. Even when you’re changing your programs behavior, not wanting to maintain tests is the dumbest excuse to not write them. It’s like saying “we don’t want to localize our application because when we make changes to English text we have to make changes to the other languages as well”.
I think that the point is clear - refactor can be without behaviour change, but can completely change the code below. That way unit tests would really slow you down.
I see E2E as the most important tests most of the time, unless you need to simulate some hard problems (like Primeagen Said with 30x speed up of a video).
This is the problem with, and Farley has the same problem, using 'just words' to describe programming problems. There should always be "here's what I mean" examples using code. This conversation is very flat and one-dimensional. Software engineering, on the other hand, is far from flat and one-dimensional. Theo's comment about [inferring] not to test stupid-simple problems is, to me, a bit naive if taken literally. I can think of many stupid-simple in, for example, authentication where bugs in the code have serious consequences. I imagine Theo would agree, ergo it's a poor choice of words to use as a coding influencer ... (my 2c).
But yes, I had the same 'flinch' about the refactoring. He did not appear to be using "refactor" in the same sense as "red-green-refactor". Sounds like he was talking more about a major (semver/breaking) rewrite (that did not have enough test coverage but the sounds of it...). That said, legacy tests are a pain in the neck when you start paying off technical debt, but then again, welcome to software engineering.
@@pegak if changing the code below causes issues for your tests then you were not writing proper tests. The underlining code should have 0 affect on if a test passes or fails. A test should only care about the input and the output. Everything else should be a black box to the test.
I love this entire discussion, you both look at the problem from different sides and I believe it's a great way to get closer to the truth. Crossing boundries of companies, industries, tech stacks, etc. is beneficial to discover WHY something works or doesn't.
I regularly watch theo and primeagen's videos, and I learn something new everyday.
Once the complexity of the system increases... no way you can keep the whole system with dynamic state, reactions and derivations in your head at once.
While covering code with unit tests, I learned and uncovered so many things, it is crazy.
Unit tests are the only up-to-date documentation for the code. If you don't need them, you are either a genius or working on something too simple.
I like reporting on code coverage in PRs, but it should be a guide for the engineers and not blocking. The change in coverage (or coverage of what's changed) should match the developers expectations; e.g. "did you cover this as much as you thought you did?"
And after a production incident your management will require x% test coverage, at which point engineers will write bad tests to pump coverage, at which point you tear your hair out
I think the point in test driven development is that your tests should represent your use cases. If you don't even understand the use cases you need to meet with the code you're about to write, you shouldn't be writing code, you should be talking with your customer to gather requirements. Just my humble opinion.
1:18 The throwaway prototype is a mirage. The pressure to move forward is always too great. Stuff tends to stick around. For a long long time.
4:00 Yes. Code is not rewritten in practise. But it’s not because of unit tests sementing it (unless they are too low level and coupled to impl. details). Because unit tests (if written at an appropriate high/blackbox level) give confidence to actually refactor the first code you wrote, while ensuring it always work. The key is to understand what the «unit under test» actually is (see: Single Responsibility Principle, which refers to business/DDD responsibilities, not any functional/code responsibility). A unit does not necessarily mean a function. (This should account for the experiences you both mention at 6:14 where you highlight the too strongly coupled unit tests).
8:36 «The vast majority of unit tests are solving simple stupid problems» should not be an issue, since you should only write (even) unit tests to reach a given level of confidence (ref: Kent Beck). Test as little as you need to: both be confident about your code AND make someone else (incl. future you) confident about your code (in your absence).
I would love these two guys to have a real-time chat with Dave Farley to tease out the nuances.
I think Theo said something like it's ok to rely on a well-tested library, but (paraphrasing) it's ok to ignore testing simple stuff you do. I think this is the key mistake. If you are writing library-level code yourself, and other engineers are relying on that working, then you need to test it appropriately. Note, that even if you are a one-person team, "other engineers" includes your future self. The other point I'd make is that should always be a risk threshold above which tests should always be written, not matter how simple the code is. And the risk is always going to be an 'it depends' problem, different for each project.
There is possibly an analog here with, for example SpaceX. They are building Starship but not before a truck load of simulations have already been carried out. I think if you look at automated testing (without getting into the albeit important distinctions between unit, functional, e2e, et al) a "I can simulate the behaviour of my code before it even hits a browser being used by a human", you are starting to "get" why testing is beneficial.
I agree with prime that the v0.0.1 is really hard to TDD and sometimes I will write a bit of code when I'm working out how something works for the first time. But I categorically disagree that tests should not influence your architecture. I actually rely on them to do so all the time.
one point which everyone seems to be missing is that the test haters seem to conflate which level you test at (end to end, integration, or unit tests) with regression testing, and then say that because they implement their tests after coding when the code is already hard to test, that testing is bad.
regression testing is a special type of testing which exists to tell you if you broke your public api before your users tell you that you broke your api. it is implemented with a combination of unit tests and a smaller number of integration tests, and the test suite exists tell the programmer that the code does what he intended it to do, and that later changes didn't break it.
literally any other testing is not regression testing, but seems to be all that the test haters are complaining about.
I teach JavaScript and have found Unit Tests to be extremely useful for checking my students' homework. I write tests both to check for correctness of assignments and for grading.
Refactoring definitely benefits from strong tests...
I just refactored our system and if we didn't have strong tests we'd be completely screwed. We missed so many edge cases...
I have not written any REALLY complex algorithm in the last 5 years. Though I got to say if I hear the word "algorithm", I already think this is a prime candidate where unit tests actually make sense.
Because in the end it's probably a PURE FUNCTION and testing it with fast-running unit tests saves so much time compared to manual testing. Plus it has other benefits like "guarding" it for the future.
That being said I rarely test on that low of a level. I technically still write unit tests though from an architectural level they are much more of an integration test. For me this worked so much better than very fine-grained unit tests that are a lot of work to write, but don't even test the thing that is by far the hardest part: integration
I think it is that fine-grained unit tests that cause people problems. We really only need to be testing at the edges of our software. Anything more detailed than that likely is not providing any value.
I only ever unit test specifically to quickly iterate over a feature I want to release. Prime's description of having to load an entire app just to test a piece of code is exactly what I would see where unit testing is most beneficial.
I think prime and theo are thinking about unit tests wrong. Test interfaces, not implementations.
Most of our industry approach "unit" tests poorly, so I consider the issues theo and prime complain about as a strawman. Your tests should express the functionality of your current story. A "unit" is a unit of functionality, i.e. your top-level interface, your API. You don't need to test every function in every class/module.
To prime's point about rewrites... if your tests are API tests, then you can rewrite your implementation without rewriting your tests. Or, if you prefer, easily do massive refactoring.
"Different version of a code comment" is what most of my tests were. And yes I'm a UI developer, so there were maybe 3-4 logic-dense functions I had to write at work.
I'd say it's a way better version of a code comment, since it tells you if it's correct. Issue with comments is, if you change something and forget the comment, it's just confusing. Unit tests if you change something and it doesn't work, you get a red thingy to remind you to either update the test as well, or remove it. And maybe add more if necessary. It's a great "example usage" sort of thing. But example usage changes, and not everything needs more example usage than the docs provide. Especially since testing a dumb function that crunches data is way easier than testing UI stuff.
It's also very useful for AoC, get input, put it through your function, see if output matches example. Can't ask for a more TDD based problem. And yes you could look at answer manually, but there's just something nice about the green checkmark.
Here's some nuance:
When you talk about writing code that you expect to "throw away", there's no reason that part of that code consists of unit tests. It's all an exploratory/discovery phase, and some of that discovery is about the "thing" you are building AND the way you might choose to test it. A set of tests during the exploratory phase can help that time, and you can even be more free/loose with adding `.skip` as you are figuring things out.
So, don't throw away testing just because your writing throw-away code, even if you are just going to throw it all away.
So what's the reason for exploratory coding? To LEARN.
I started at a company only doing unit tests, got good at it. Went to a company with only integration tests. Now i do both. Both have their pros and cons. I lean towards unit tests because i end up finding all edge cases at the start i could think of
Start with e2e/integration/api tests and write unit tests for hard stuff or stuff that is better tested as unit test, simple enough
This is what I also prefer. For most of us in CRUD apps, there is a much higher ROI with integration tests, because there is often little complexity in unit tests. Also, people are traditionally poor at writing unit test and start building tests which are make heavy use of mocks and end up making refactorings extremely hard. Unit tests are awesome, but you need to have the correct problem to apply the solution.
Exactly we don't need excuses to write unit tests, we need solid reasons. E2e/integration tests are a good starting point
Sometimes, rules like "80% code coverage" get made because the developers aren't employing personal disciplines. Other times, it's because companies are struggling to smooth out the spikes of bug reports following release cycles. We're not perfect as developers, but we can often be more disciplined. If we don't self-regulate, then others will probably regulate for us.
I agree with Prime saying unit tests supports development but I don't agree it's not also for safety. My point is that when they break you can check if you broke functionality and evaluate its impact on the whole system, if you don't you can easily forget and the system doesn't behave the same. But please don't keep unit tests that bring no value just to meet a braindead metric.
You want to know the real secret? When you're about to write a test, ask yourself "will this test add actual value to the codebase". If the answer is "no" then don't write the test.
This is an organizational argument masked as a technical argument.
dynamic programming... lol that is really funny because it is a memoized algorithm and you already know the inputs and ouputs before you even code the solutions. Therefore unit tests makes sense because you are working with mathematical equations and you can predict the final result. Unit tests is to prevent yourself from implementing things incorrectly. If unit tests are simply us doing console.log then we are doing it all the time lol
I have my own micro-orm library and I think it's great, it does everything the exact way I want it to do, it's as simple to use as I want it to be and I never written any single unit test for it, probably will never. But then again, I'm the absolute sole user of that library
As a UI and a backend developer that only touched CRUD functionalities. I agree that I am just a monkey and 10x devs are my gods.
Looks like VP9 is working better than it used to, I saw no drop in bitrate when the confetti came in.
I tend to model everything using state machines, and after implement it them for me unit tests are indispensable to check that i didnt make any mistake when going from design to implementation.
My the other main use case for unit tests is when manually parsing data, sometimes i have to read a command line output and convert a set of tabular text data in to a struct, for that unit test is the only way of getting it right.
It was funny. People at one company I worked for loved tests so much, so one day I just gave up, said feck it and write a parameterised test that adding 1000+ extra tests to the test number on the report. Almost completley useless, but damn did it make people happy haha. It was hilarious.
Here's my take: most web apps are CRUD/UI, hell even like 80% of a big site like FB or Twitter outside of something like the recommendation algorithms is CRUD/UI, and for CRUD/UI, the move is to get as much coverage while testing as little as possible - in this context unit testing every single component and function makes no sense. For my CRUD (mostly R)/UI app, we unit test helper functions that are also used by the end-to-end tests and do strictly end-to-end tests to get most of the other coverage. Unit testing all 100+ components would be an insane time sink.
10:49 also I am currently importing and adapting e2e tests (Cypress) written for my web app (T3 Stack) to my upcoming mobile app (Ionic React with Vite, Tailwind, and Capacitor), which has a 75% identical codebase to my web app except for some mobile-specific things and I am definitely removing tests from the mobile test suite that are only relevant to the web app - for example: show a 404 page when the user types in a nonexistent URL, which will 100% never happen in the mobile app since this is physically impossible to do. Why would I keep those tests in the mobile test suite?
I think in every program written there are only specific points where side effects occur(e.g. writing sth to the database). So everything else can be written in such a way that it is unit-testable. Analyse where your side effects are and then test the rest.
I agree. Clearest communication yet. I don't like integration testing though. On a decent sized code base it's annoying to figure out why an integration test failed and often not an indication of an issue, nor proof there are no issues. There's likely to be too many permutations for integrated tests, and if there aren't, more than likely, you could have done unit tests and it would have been superior. Also reinforces some weird or bad habits.
Just to clarify something: The I-Frame in a video is the delta frame (the compressed frame). The P-Frame is the uncompressed frame. A Group-of-Pictures is comprised of a P-Frame and many I-Frames
This is why I prefer integration testing. Given this input from the api, this should be the output. Then the internals can be refactored and I know if I broke the public api. I only test internal types when it is a critical component to get right, such as a price/tax calculator. I love automated tests, but I start with integration testing the positive cases and then create unit tests for complex logic. Any bug which makes it into the main branch must have at least 1 test added in the hotfix PR.
Additionally, I highly unit test domain types since that is the actual business logic. This should require almost no mocking with these, since domain types shouldnt not have access to external libs. When it is absolutly needed, I use an interface/type to abstract that logic.
Unit tests are indispensable for refractors. What Theo did sounds like more of a rewrite than a reactor.
love this video! btw, have you realized that at 26:30 you described why learning vim (neovim) is worth it? :)
If you have a business layer that literally is a mirror to call your repo layer. Yeah, it's dumb to write for your business layer, write for the repo, you can test many aspects. If you aren't doing paging, that might be bad, write a test to test you are not dumping the whole Set. Test if you are retuning only info you need, not the whole entity. You can do so much, if you know where the value is being brought. I agree, they are idiotic when done without critical thinking, but if you do analyze your code base, and you do find the places of value and you add that safety net to them, you do better engineering. Tests saved me countless amount of times before doing something stupid, and also helped me debug so much faster. They are not your enemy, if used correctly.
In my opinion, E2E and integration tests are great, and unit tests help with development. I write unit tests so I can run and test the code as I write it. With vscode snippets and Copilot, it's also very fast to write them. Unit tests do speed up the development, but it depends on the project I guess.
The right tool for the job, not the right job for the tool. Unit Tests aren't a silver bullet. Even then if a problem is complex enough or solving it correctly is critical enough for your app you should unit test it.
In a lot of places I've worked many unit tests could have been completely avoided if you use a language with good static type checking. TypeScript is a good step in the right direction, but because these language still have non-type checked error handling (Exceptions) there's still tests you need to write to make sure you are handling all the edge cases.
I'd like to add, that unit tests that test specific business logic, like calculating a value correctly etc are the most valuable type of tests. Testing that objects are the right shapes is something static type checking should be handling.
I like that take "test things when they break, and test things when theyre hard"
i like it because my code never breaks and I find everything easy
One thing I want to add the poll result will be different if prime have did it. bc most of theo's audience are react dev.
Hot take, even though unit tests are often forgotten on the frontend, they are just as important. And have gotten easier than ever with tools like vitest.
Would love some talk about doing inside out vs outside in tests: i.e. London vs Chicago school of TDD. If you test your implementation that is what causes it to break so much. Unit tests are so easy to do wrong. I also think that when you are on the level of Theo then testing might not give you as much help . I think a bit more like Kent Beck who says he unit tests because he isn't that smart. Would love this going more into the talk. TDD and Unit tests force you to have better, more testable units. I also think that unit tests provide contracts that make devs think twice about breaking something or some edge case in functionality.
This video was both informative and a great way to add some imposter syndrome back into my daily life.
@Theo:
At the time you were doing your push-back against unit tests (probably justified), you probably weren't aware of how little automated testing was being taught to new programmers at post-secondary institutions. As educators (that's me), we're so far behind the curve in terms of disciplines like unit testing that some of us have been ringing that bell for years trying to get our students prepared for the work force. I tried getting us to include unit tests in one course back in 2005, and only recently (2022) are we starting to actually include it in some of our courses. The major stumbling block: instructors. This is for a 2-year diploma at a "leading polytechnical institution".
Change, sometimes, happens at the speed of tenure.
I think this is the primary issue. The industry as a whole has no idea when, where, or how to write tests, and it starts with so few of us have any good formal training on it. Add in most legacy code is not written in a very testable way, and you get pushback due to ignorance. We don't need the extreme of some TDD advocates, but we do need to be writing tests.
you can make good use of the arguments you will find in pull requests to get a good indicator of the maturity or confidence of devs in your project. if you added a pure data holding class that will miss the coverage, observe. if you integrate a external library and somebody demands a comprehensive testsuite for it, observe. if your test is plastered with complicated mocks and no one has an issue with that, observe. mistaking guidlines as rules, testing dependecies instead of testing your own code and poor design choices will be revealed to you this way.
Every good team I’ve ever worked on had good testing culture. Every bad team didn’t.
i don't do dynamic programming stuff (anymore) but I do something even crazier which is regexps and I need to test the hell out of them
for backend webservices i break my middlewares into testable chunks. then i have a few "manual returner" and "log" middlewares i can place at any point in any route and match outputs with expected output hardcoded in my test scripts. my test scripts are httpie cli wrapped in bash, or i just use thunder client to eyeball it. i can unit test everything with http using modular middleware. and can have specific test routes that are dynamically loaded at runtime if specified
those headphones you're wearing are a huge W, they're great for livestreaming, you can get a boom mic cable for a tenner that sounds great.
the phillips shp9500 and 9600 are both great pics.
Tests define the requirements from your code. If the original developer who wrote the code leaves, the test harness will inform me of what the behavior of the code is supposed to be. Untested code can never be refactored with confidence.
Personally, I like to write integration tests as they cover large code paths while having to write less tests. They are slower but add a lot more value.
I still think CRUD testing is important even though the logic may be simple.
A lot of great wisdoms and sentences in this video
Appreciate it 👍
At the very least, I'd say unit testing for the critical path is a bare minimum. Other than that, it's just generally good to be pragmatic about unit tests, integration tests, and end-to-end tests. 👌
'my unit testing "coverage"' 😂😂😂
OMG, yes please. Can I suggest we are all talking about different things. Unit tests are well understood, but when you are building a test to test some complicated code with multiple steps or pieces of data, that isn't really a unit test or a functional test. It's more like a JIG or a platform to build with. Can we have "Jig Test's" or something with a better name that is not a unit test or functional test? Then we can all agree the days of unit testing are done and we can move on building jigs when we need them.
we already have them, and they are called end to end tests.
they are particularly prone to being used by ui developers, but are also generally disliked by all testers, as they often depend on hidden implementation details in code that was never designed with testing in mind, and thus are both hard to do, and prone to breaking.
this is why the testing pyramid was developed, regression tests lower down the pyramid depend on fewer hidden implementation details, and thus don't break as often. tdd was then developed on top of regression testing to get people to write testable code.
Very cool mini lesson on video data compression 🍿
It’s just the time of the year, in one week the fight can start again
I like Prime but a lot of thing he says is really something that the major developers never gets to do like really hard algorithms. Most of the developers working in normal companies just build a CRUD or services and solve problems that doesn't need that deep knowledge on the hard things Prime says. However I do think it´s good to get that ability to build a hard code base in my studies, you never know when a scenario like that could come. I am a middle software developer and if you are starting in the career, don´t get to much stress about going to deep in knowledge, take your time and keep doing the basics well done.
I think it doesn't help that default tests that people are shown are typically rubbish to use. For instance, the typical React Component "it renders successfully". There's very few cases where this would be a useful test at all, and instead is typically incredibly fragile. Especially if the styling has hashed naming.
The main things which I test is key logic functions that is important for the work that I'm doing, where I need to either prove correctness or that I might need to alter if the client changes their specs. If they do change the specs, I can alter the test and then adjust the algorithms until the tests are happy. However, this kind of work is non-typical for web devs.
I'll argue on the refactoring as testing can be useful on that, though it's probably more an integration test or e2e test at that point. Ie, you have a black box where given inputs you know you want these outputs. Tests let you refactor inside that box and ensure you don't break the functionality. However if your tests are too prescriptive on what happens in that box, then you're just coding in a straitjacket and you won't be able to meaningfully refactor. Annoyingly this is what those default tests tend to teach people to do.
I would've loved to test the current backend I'm working on but then I'm still required by the FE team to put the new api docs on postman still; so I'm not gonna wirte any tests when I'm still gonna go to postman to document the new apis and then manually test them as well. The best I could do if I cared so much about automated tests would be to use the postman api collection integration testing feature so I don't have to do double the work all for testing.
You need tests to prevent your teammates from breaking your shit.
"unit tests are the useEffect of culture" banger quote
The IFrame is the base where diff is then provided for each next frame, that is why you get funny pixelation happening
4:30 An interesting point. Deleting unit tests does hold a stigma. While you can comment and justify why you're deleting said unit tests (rewriting the logic), generally it makes you look net worse at the end of it all -- even if you've just improved an existing process.
Theo later brings up a good story referencing this issue again at 10:40.
I started watching you a couple of weeks ago and couldn't shake off the feeling that I know you from somewhere xd
I just realised that you remind me of an actor Adam Scott from Parks and Recreation and the Severance haha
Anyway, great content, keep it up :) I really enjoy those videos. And Happy Holidays!
It's weird how much effort is needed to undo the dogmatic crap that a lot of the industry is built on.
I've personally seen way more projects hurt instead of helped by clean code and unit tests because of the "everyone does it" attitude.
If you don't have a valid reason for doing something, then don't do it. "Code smells" aren't a valid reason.
I've seen people accusing of prewatching the content they are reacting to, but the content itself prewatching the reaction? That's new
Actually, nevermind, it happened to Prime once when he was reading an article
11:41 for a sec I thought of s as the invisibility frames in dark souls dodge rolls...
the fuck is wrong with me
10:26 Omg, The version of the facebook engineer story I read was, he went to work for Uber and when he deleted a test that was preventing him from pushing code or something, and the other Uber staff commented (in the post i read) that, maybe at facebook, a failed unit test isn't a big deal for user experience the same was it is at Uber, since they're fundamentally different products ?
Still, very funny that we potentially have a two separate facebook engineer stories about unit-testing.
It might be stupid, but I find my self verifying inputs and outputs inside the target function itself, as opposed to uni-testing it from outside. Most of my code doesn't give a buck about performance tho.
This is so good content I am delighted
As CRUD engeneer this video open my eyes to what real programming looks like
I'm someone who opts for TTD, but I like your take. How much does linting play in protecting the quality of code that maybe invalidates a lot of the argument for TTD?
18:20 - "Test what you detest"
A big part of this that isn't being mentioned is that unit testing react is hell. They're almost integration tests at that point, unless you're testing hooks or pure functions.
I mainly write FOSS libraries, so testing is really important.
where i work, all our repos are mandated to be 100% test coverage, i have mixed feelings about it
Prime speak so fast, that it's better to set playback speed 0.75 for non-native speaker as me. And Theo also speaks in quite a pace.
Could not live without unit tests, im native Android apps using kotlin for financial institutions. Has to be done. And its nice to do with mocking tools like mockk and good architecture enables that.
In this yeah i will fail a PR fhat does not have tests. Ive had a PR before where i added the test and it failed because they were calling the same thing twice... it works.
I write code, my copilot writes my tests...
Nice my comments showed up. Honored.
I can hit that bullshit 80% metric for frontend if we count TypeScript typings ensuring 95% of what happens already. I only write unit tests when writing complex utilities, for example a function that takes a Skill of a game character and tries to find upgraded versions of that Skill, or maybe it was a spoilered version of that Skill (i.e, name: "???" until something was revealed in the game's storyline)and I'd like to use the name (because that story chapter released multiple years ago at this point and the game itself abandoned that spoiler system, but kept it in there for newer players)
I just did 8hrs of unit test today.
I've been a c++ dev for 8ish years now and I've never wrote a unit test though I tend to write code that either works, doesn't compile or phails spectacularly
Also, I don't think about algorithms in a way that makes it possible for me to unit test my algorithms... I think it would be near impossible for me to sit down and write a API in the traditional way.
But I wouldn't say I hate unit tests. I would say they are quite important for a certain workflows , however, I just am incapable of thinking that way.