I find the biggest hurdle with a lot of people when it comes to unit testing is around 6:30 ish. They think the tests are supposed to exist to find bugs, vs existing so that expected behavior is documented, which has the ultimate result of reducing the chance of introducing a regression bug.

Having worked with horrible legacy code with zero tests, written by many engineers who had left the firm, I shudder at the thought of writing anything new without unit testing. I can't believe that 20 years after the TDD book was published, people still doubt not just TDD, but unit tests themselves!

@CodyEngelCodes

Жыл бұрын

People still assume it means you write every single test up front too which baffles me. TDD is not that difficult once you start doing it.

@saritsotangkur2438

Жыл бұрын

Love unit tests but hate TDD. Writing tests first creates bad architectures/apis. Focus on making good architectures first that can be tested. Only way to know if you have a good architecture is to code first and refactor based on your learnings. Then after you have the right interfaces and separations of responsibilities you’ll know what responsibilities to test for in each “unit”.

@Sudhang

Жыл бұрын

@@saritsotangkur2438 That's reasonable and not uncontroversial: Fowler's book "Refactoring" mentions this. However, I don't agree that it is impossible to write reasonable architectures with TDD. I don't agree that they are incompatible

@sustainableCode

Жыл бұрын

@Sudhang just like people says Dependency Injection is just a fancy way to pass dependencies to an object.

Unit tests have saved me so much time. Having a good test, doing a refactor on the code and being able to find where the refactoring isn't working because of the tests is such a life saver. But write useful tests. And when something isn't working and a test didn't pick it up, write a test to catch the problem, THEN fix the code.

I don’t like writing unit tests but after 5 years of running my own SAAS company, I realized their importance because I created the software few years back and now I want to upgrade, refactor and add new features but there is no tests so anything I touch breaks something else. I spent 2 months writing only tests!

@CodyEngelCodes

Жыл бұрын

It's easy to have a love/hate relationship with unit tests. It took me a while of writing unit tests to realize that it's actually better and easier to just write them upfront. I'm hoping to cover this more in future videos with some nicer real world examples but until then I'd say this: How often have you added code that wasn't necessary just because you wanted to be safe? How often did you write code only to realize it didn't work when you went to manually test it out? The great thing about writing tests, and writing them up front is that you are only writing the minimal amount of code needed to make the test cases pass. On top of that, if you are writing the tests and running them to validate the code works, then you're spending maybe 20 - 60 seconds per test as opposed to 60 seconds to manually test the code only to realize it needs to be fixed and debugged. Of course though, until you've spent a lot of time writing tests it's hard to see their true value. Also you usually want to go through a project re-write to truly see their value which doesn't happen until or year or two down the road. Anyway, really happy to hear you've seen the value of tests, and also congrats on the SaaS company, you're living the dream ☺️

@CallousCoder

Жыл бұрын

I never have that problem. I test my functions (very small and simple) as I write them, works move on and I hardly ever touch a function again. And writing unit tests for system software is non-trivial I rather test end to end and integration tests. That’s value for me. A single unit of work, I can reason that logic even. A little print to a console to see if the outputs match infinitely faster.

@joanvallve7647

Жыл бұрын

If you had tried to run your SAAS company writing the unit tests first, you would still be working on it 🤣 Unit Test might be useful in some cases, but in general they only make you lose your time, focus and money. No wonder everybody was doing unit testing while money was for free and everybody loved to burn money on endless software projects. I bet nobody will be talking about unit testing as long as inflation is high and money becomes an important part of the equation in software projects.

@joanvallve7647

Жыл бұрын

@@CallousCoder Totally agree. 👏 That's the way everybody should be testing instead of losing time, effectiveness and money doing unit testing.

Hello new friend. I was watching one of Theo's "reacting to" videos on anti-OOP (which was really him just watching). Then saw yours reacting to "Clean Code v. Dirty Code." And landed on this one reacting to Theo's thoughts on Unit tests (coming full circle in some sort of meta-way). You are right on the money in both your reactions. The Dirty Code guy probably doesn't work in a domain where Clean Code is beneficial, and Theo really doesn't know what he's talking about. I wish *you* had Theo's 270K subscribers - they'd all get better advice from you. I'm subscribing.

Every time I learn some nice clean coding techniques, I'd think of how I can apply it to my old projects. But then refactoring it always felt daunting because I would need to manually test it and just the thought of it made me put off making any changes to existing code. That is when I understood the value of unit tests! Then of course I started writing them wrong, now I'm slowly learning to write good unit tests! Glad that I learnt this before I built any complex system without unit tests! Earlier I used to love making changes to repos that didn't enforce testing because I could quickly hack something up, now those kind of repos make me uncomfortable :D

@CodyEngelCodes

Жыл бұрын

It can certainly be a balancing act, but for anything that you'd want to last for more than 6 months, having tests in place will only be helpful down the line. I'm working on a silly python project for a video and I'm not writing tests for that because it's just going to get tossed out afterwards.

Unit tests have saved me sooo much time. Idk where theo gets the idea that they slow us down.

i would love watching a discussion between the two of you, as a junior-ish dev i find this topic super interesting

@CodyEngelCodes

Жыл бұрын

Maybe one day.

@HoD999x

Жыл бұрын

@@CodyEngelCodes i can take the place of the no-test advocate :)

Happy to see someone else having the option that unit tests are documentation first and foremost

@CodyEngelCodes

Жыл бұрын

Happy to see someone else shares the same opinion as well ☺️

Tests ALWAYS improve my code, ALWAYS. I have even gone as far as mocking input and output of my hardware to model the serial connections between devices which is incredibly useful not having to alway rely on running it on the actual hardware. It means I can clear out bugs BEFORE I even get to testing it on the actual hardware. It saves so much time.

😆It's funny because almost 100 percent of your dialogue while watching his video was the internal dialogue that I had with myself while watching his video. I think one of the main things is, like you mentioned, his experience is with unit tests trying to test stupid things as opposed to behavior due to the codebase not being type safe.

Whenever there is something that is frequently done badly, there will always be plenty of people who smugly believe that it shouldn't be done at all.

Tests usually dont catch bugs. They serve as a definition of the use case, given this input I expect this output, this is especially useful for refactoring, but not for catching bugs. And anyway, most of the time when you refactor you end up changing the test because requirements also changed, whats the point?

Nice video, unit testing is important

@CodyEngelCodes

Жыл бұрын

It sure is!

I am a strong proponent of testing a lot. But at the same time a strong opponent of unit tests in the majority of cases. For certain tasks, like "outward facing / broadly used" functional libraries or APIs not dealing with a lot of state, it makes sense to have a ton of tests that 100% encapsulate the specifications of each call. In those scenario's it will pay off and the codebase naturally is static in its specifications and a lot of code likely depends on it. That makes it worth a one-time time investment. In nearly all other cases specifications get extended/change on a regular basis. So it works against developing good software and testing it well. Writing good valuable tests is actually orders of magnitude more involving/harder than just monkey testing things as they get developed. Even more so than delivering a math proof is over delivering a correct answer and nearly all of the time there is an infinite state involved (in real applications). So writing unit tests then means LESS testing being done and it becomes more of an exercise of purity and religion. And writing less than complete tests is just a waste of time IMO. And using unit tests as a means of forcing a "testable architecture" is dangerous and will lead to catastrophically poor code that is way more complex than it needs to be. This will cause all sorts of issues during and after development. Quality first and foremost means it does what it must do reliably and that means non-automated testing its output given expectable states and some outliers, just to see if the mechanisms work as intended. This places zero demands on the architecture and it can be made as efficient as it needs to be, or coded the most efficient way, whatever is most important. But unit tests are NOT that, it's mindless code and it will spot nothing out of the ordinary! Theory often only holds in static scenarios that are also quite simplistic. Real application code is pretty much alive and always deals with states, internal as well as external. Simulating it all or worse, mocking it, is just a lot of work and extra maintenance that does not catch any logic errors. The person doing the testing will typically be the same person that writes the test code. And the amount of work for real applications will be a project in and of itself, not 20 seconds per test. That would be 20 seconds wasted as in that time, nothing meaningful can be tested. TL;DR More code written by humans = more bugs!

@joanvallve7647

Жыл бұрын

Your comment has so much wisdom inside, that I can only feel pity imagining you alone suffering in your scrum team while hearing again and again those bunch of idio.ts saying how important, necessary and fundamental is unit testing to produce good software. Keep on going and stay optimistic. In 2 or 3 years nobody is going to use or talk about unit testing anymore.

I find the value in having unit tests very useful. It helps to think one more time and make the API of the unit better so it is easier to test and use. Then the unit is often better to reuse in other places as well. I to not hesitate deleting unit tests I do not understand once they brake. sometime the setup in unit tests so so humongous that it can waste time. but until they break and waste time, they likely saved lots of time before. I like when a machine is telling me an issue with the code, not the QA team or end users. I have never seen a culture of "good unit tests". people want it, but don't know what it is. and I think a lot of coding and debugging goes into figuring our how that library or framework works and configure it so that it works, instead of actual code. people are so afraid of coding, they use libraries, and then we hope they work, not realizing that implementing some features without external dependency can be easier. and,... did you just mock the dependency away? if people use dynamic languages, I recommend using assertions in the code, not only in your test code. so you can still be sure of types. in a previous company, I was looking at the production and staging logs, see an error message, and it happen that once QA get to me, I already deploy the fix. the guy is happy that a bug can be fixed in 7 minutes, however with some automated check, the 7 minutes had never been needed to be spend. and maybe unit tests are not about getting fast. but to be predictable. so you don't need to spend the 7 minutes on a weekend, with 3 times salary rate. I wonder when companies will actually understand that the actual time of coding is not costing so much money. but the process of making decisions. Finding not just a good solution, but a solution that makes the user, and the manager happy. often the need to please stakeholders (such as with coverage number, or the use of "can to everything framework", or the time spend what of 5 solutions is best, when it does not matter and any solution would do, but will by boss accept my solution? I need a reason for any of the solutions that sounds good,....) ok, I finish my rant here,... I hope the two of you can get more discussions on the topic

You shouldn’t be worried about changing because you can run a whole run and see end to end with your production set if things are still compliant. End to end tests are important unit tests you can do easily by hand - when you code properly and have single purpose functions. And the number of public functions I expose are always the absolute minimum.

Contributing to a codebase with no unit tests sounds terrifying. There could be a million assumptions on weird or broken behavior and fixing things could cause several others bugs.

@CodyEngelCodes

Жыл бұрын

Yep, pretty much. The issues also don't arise right away so the original engineers look brilliant in their ability to just write code incredibly quickly while those that follow them look like idiots as they try to untangle the spaghetti.

I've worked on horrible legacy code with very little testing, I've worked on over-engineered legacy code with a complex unit/integration/acceptance test framework, I've worked on new green-field services. A good test suite is amazing and will save you so many silly mistakes, bugs, unnecessary pushes to some remote environment. I know from some point of view it looks like engineers not focusing on the code that makes money, but if an engineer's time is a major cost center, a decent test suite from day 1 will keep them productive. Other benefits: PRs. Having tests in a PR make it so much easier to review how one would use any interfaces and structures built in the code; they make good talking points and teachable moments. Even cumbersome test suites have a utility: A clunky test harness can be an indicator of a troubled architecture.

@CodyEngelCodes

Жыл бұрын

I don't think I could agree more with what you've said. The fastest way to build software is to do so in a steady manner that keeps quality at the forefront. Sometimes the quality will need to be sacrificed but that doesn't mean we should optimize for crunch time. Code with tests is easier to work with because you spend less time manually testing the changes. Write some new tests to document the new behavior, validate that the tests all pass, and then ship it. Get in, get out, and move on.

The crucial concept is at 7:00 here... "Expected behavior". Because the sad reality is that most software engineers at most companies write unit tests against implementation details, and not against expected application behavior. And the consequence of that is two-fold: First, the tests will indeed cement in the current implementation, preventing or at the very least significantly hindering refactors and code quality improvements. Second, the tests will not help to identify if the application works correctly, in fact the tests will fail even when the application behavior is correct. So, even though a lot of software engineers would think that arguments about "avoiding testing implementation details" are some sort of pointless pedantism or dispute over semantics, in fact this is arguably the most important principle of testing, which differentiates tests as a liability vs tests as an investment. Which further means that defining the 'unit' as a unit of application behavior is also crucial.

I don't make tests with my own code. Nobody else will touch it anyway, other then me. Besides, I do have certain "checks" in place that will yell if something is incorrect. Rust, PHP, love those 2 coding platforms, but C++/C, well, you can very easily create a havoc in your code and memory usage.

I've worked as a software dev for about a decade now. TDD has become my go-to method for writing code. Unit tests ARE NOT THERE TO SLOW YOU DOWN. If that's their function in your org then you're writing bad tests that are testing implementation instead of behavior.

In some cases, mostly small solo dev projects; unit tests are meaningless. UTs become highly important and relevant when multiple engineers work on the same codebase and engineers moving in and out of project over a period of time. As a lead/architect/manager; the only way I can sleep peacefully at night is because I'm aware that every PR has a valid UTs and sufficient amount of coverage. Unit test and code quality are 2 different things. If you don't have guards to check if an object exists or not before operating on it; that is a code quality issue. UTs may or may not help you uncover that.

@CodyEngelCodes

Жыл бұрын

Agreed, if it's a small solo project then the need for tests becomes less important since you're the one that knows how it works and will be updating it going forward. Can't recall if I correlated code quality to unit tests in the video but also agreed that they are two different things. You can have good quality code without unit tests and you can have terrible code with many unit tests, although if the tests are written properly it makes it easier to turn the terrible code into quality code.

@khatdubell

Жыл бұрын

I write unit tests for all my solo projects. Not only does writing the tests help me think about the problem and how i want to solve it, but more importantly how i want to express it in terms of an interface. Once i've ironed out all the behaviors i want, the code writes itself. When all tests are green, the functionality is complete and i don't have to even think about it.

During this video I found myself rolling my eyes a lot. You were explaining what unit tests were like we don't "get it". We know what they are. We disagree that they function practically in the real world as advertised. A huge red flag for me is the constant "no true Scotsman" arguments you make, whenever someone describes actual experiences they go through where unit tests provide 0 value while consuming a huge amount of resources. It's the same thing I used to hear when I would complain about issues I would have with the object oriented paradigm and how i believed implementing code "correctly" involved a certain amount of fortune telling. They'd inevitably assume I just didn't "get it" and explain, as it's always possible to do after the problem is understood, how I misapplied whatever it is that they are preaching. Same shit with unit tests. I find that people don't mess up units and that they're not difficult for developers to understand or implement with or without tests. The weak points are always 1) how units are built up to make more complicated things 2) but actually you made your units wrong in ways that are impossible to predict until you've done number 1. So fuck em. Imma focus on what's hard. Not on what's impossible

I barely write unit tests and if I need to, it's mostly for modules which I know are going to be fragile. However, I always do integration tests (this is a non-negotiable for me). It's not that I find unit tests useless. I agree writing testable code makes it cleaner. It's just that based on my experience personally, it just slows me down (similar to Theo). Most of the mistakes I often encounter aren't usually caused by the modules themselves but on the overall design of my software. Moreover, most of my projects aren't even mission critical, so that's also another factor to consider. I think we're becoming as dogmatic as we are with Agile/SCRUM. If a developer isn't a fan of writing detailed unit tests, then we should let them be as long as we're following regulatory requirements. Forcing a specific kind of workflow is not really good thing in this industry.

I've spent a long time writing code -- often as the lone programmer supporting a small office -- and for much of that time I didn't use unit tests. (Or, y'know, version control and other such wastes of time...) When I learned about unit tests, though ... I started using them. I'm far from perfect, and I often seem to write code that is not easily testable, so I've still got plenty of room for improvement, but the idea of *not writing tests* now seems just ... odd.

do we need 100% coverage when writing our unit test ? I have a big issue , any time I am writing unit test, I ended up updating my logic for it to fit with the unit test. is it normal for other developers here ?

@CodyEngelCodes

Жыл бұрын

You don't need 100% and writing testable code tends to be better code so that sounds normal.

Say I need to go out and do 3 errands, and I expect it to take about an hour. Now say we as a society decide that safety always trumps convenience, period. Now it takes 27 minutes to get into (and get out of) my car's newfangled safety harness. My 3 errands now take 4 to 5 hours. The point is: if safety is your only metric, then you sacrifice everything else: time, money, frustration, morale, focus, productivity, customers, shareholders, etc. Tests are tech debt, and a crutch for mediocre developers. Competent teams just get stuff done, and the results are better over time than those drowning in self-imposed bureaucracy.

Oh here ab analogy from my work as an EE (far harder than CS) You develop a piece of the solution on the bread board you measure input and output (that’s an end to end test) and you draw it up in cad. There’s no need to ever test the individual ICs and components! And then we build the next block. And then we make a proctor that we do the end to end testing on because the actual signals and frequencies in the whole system are the only real value - again end to end testing. And we do that automatically because we throw everything and the kitchen sink at it. And only then when it survives we go to production. Because we can’t patch it. That’s my approach to software engineering as well. And in the rigorous end to end testing (and sometime by hand like now with infrastructure of code because we can’t automate everything since we don’t have all the rights in the pipeline (thank his, would be a great attack vector) we find bugs and issues and weird edge cases that none of the unit test teams found. And they are always confronted with those issues, when SaaS misbehaves, we tested this we simulated this (often by hand) and we recover from it. But again that’s system/integration/end to end tests and not the smallest unit of work as a standalone unit.

@jeremywindfield2658

Жыл бұрын

Aint nobody gonna read all that

@CallousCoder

Жыл бұрын

@@jeremywindfield2658 then you are in the wrong profession 😉

Can slow you down if you are new to it... The true gem of Unit Tests happens when you are productive and no bug coming back for you.

@raymundenso

Жыл бұрын

I'd rather have new feature/s added than bug/s

Unit tests are easy to write - once you've written the first one and set up the mocking. Keeping the amount of assertions to the minimum needed to test exaclty what you want to test can also be a bit of an art sometimes.

Needless to say; I wouldn't work with/for a person who shares the same beliefs as Theo. There is no need to have such strong opinions right from the get go.

I generally agree with your argumentation, but for my personal projects, at least when prototyping stuff, i usually don't write unit tests as it would slow me down, as i try out a bunch of stuff and refactor often.

@CodyEngelCodes

Жыл бұрын

TDD is a tool and is usually best used for professional projects. When it comes to prototyping or just trying to throw together something quickly that isn't intended to go out into stick around for a longer period of time, then writing tests is usually a waste of time -- although it can be helpful to quickly learn about a new library or SDK.

Most people that hate writing unit tests are either really bad at it or write their code first and then unit tests. If you are solid at writing unit tests and get into the habit of writing your unit tests first (i.e. TDD) then you tend not to hate it so much and actually find that it saves your skin in a lot of cases.

@CodyEngelCodes

Жыл бұрын

Yep, agreed!

I see several saying the point is to document... why not just add documentation?

i prefer having only few tests that run through complex use cases. little effort, great benefit

Hi there! Have you heart about Bootcamp at Meta? =)

@CodyEngelCodes

Жыл бұрын

Yes

I'd be really curious what projects/companies Theo have worked for and if he's aware of Martin Fowler and Robert "Uncle Bob" Martin. For small greenfield projects maybe unit tests would be cumbersome, but the more features, dependencies, integration points, and code changes a codebase have to make, the more unit tests become a crucial component for the team. Cody and I have both seen what happens when legacy code doesn't have adequate test coverage and it's not pretty. I would be curious how Theo would handle refactoring a legacy codebase with minimal test coverage.

@CodyEngelCodes

Жыл бұрын

"Cody and I have both seen what happens when legacy code doesn't have adequate test coverage and it's not pretty." I still have nightmares of scrolling through that one class (which I won't name & shame) and thought to myself "I've been scrolling for a while, which functions have I passed up?" only to realize I was still in the same function. It was hundreds of lines long and I think still actively being modified by a COO 🤣

@Rasengantrue

Жыл бұрын

@@CodyEngelCodes Haha oh man..... I felt so bad for the teams that had to interact and maintain that codebase.

@t3dotgg

Жыл бұрын

Robert “uncle Bob” Martin the climate change denier and Martin Fowler the “don’t commit til every bug ever is solved” guy? Great sources of info for devs

@CodyEngelCodes

Жыл бұрын

Theo -- thank goodness Uncle Bob isn't in charge of resolving climate change and sorry but Martin Fowler has never led me astray.

@Rasengantrue

Жыл бұрын

​@@t3dotgg I'm gonna compare this to the DNA Pioneer James Watson. James Watson has said some very foul things in the past that he should be held accountable for, but that doesn't dismiss the work he's done in the molecular biology community. Just because someone have a checkered past or flaws in their character doesn't mean that the work they've done gets dismissed or automatically revoked. And this is the same for Robert Martin. I don't entirely agree with every Fowler and Martin has said in the agile world, but they have been the pioneers in making refactoring and TDD with Agile/Lean methodologies a crucial aspect of the software world and has drastically improved our lives and the lives of many other developers in the process. In conjunction to reducing the code smells in legacy code bases.

I think the "maybe you fix one bug but introduce 15 new ones" wins

I don't write unit test. I write test in the code itself. I build things alone so that might be part of the reason, but I think writing test would be a time waster when I can test the program in the actual program. I deal with IO operations, I think test is best for frontend developers, not for full stack or backend developers. I debug my code very fast, and I don't depend on a separate test. Every error is caught in the code base it self.

@CodyEngelCodes

Жыл бұрын

Tests are actually great for IO operations and they are another way to run your code. If you want to manually test that code every time it changes, then sure, don't write tests. If you want the ability to make updates and only manually test the new behavior then you should probably invest in writing tests.

Like, I don't understand his argument. Is he saying don't test the code? If not then like, the only difference between unit tests and his methods is that after writing a potential fix then you have to start up the program, manually set up the situation that needs to be tested, reproduce the problem live in the program by hand, then shut it all down before making a change and doing it all again is... all that long tedious boring stuff I just described between the steps of writing code and seeing results lol You know, the stuff that we as programmers like to make the computer do because they are faster at it and less likely to get bored and forget a step somewhere along the way. Perhaps he IS suggesting to just not test the code. It kinda sounds like his plan is to just write something, release it, and hope that it probably works and if not no big deal cause the customers have been co-opted into the development process. I don't know what 'Ping' is or what they do but I know I don't ever want to find out now.

The only block for engineers is QA, what bastards always trying to make my life harder. Lol

I write the class and the fastest way to debug it without running the whole big thing is to write unit tests.

3:59 Bro!!!! That's exactly what tests do!

You hate these guys who are so reckless to want to do everything quickly without doing much things. Like in front end it happens more frequently

Considering the number of shity bugs we get in all apps, and particularly meta products are full of issues, saying you do not need tests is not bold, it's suicidal

Unit test catches the code in its assumed environment.

programming: 99% - people talking about which language, philosophy and workflow is better and disagreeing about whether their buzzword-of-the-month cup is half empty or half full 1% - people actually writing code.

@CodyEngelCodes

Жыл бұрын

Happy to be in the 1% ☺️

i wonder if the people who made the UK postal financial program had unit tests? i bet the programmers wrote the program had Theo's attitude.

Unit test are great for large teams, and a death sentence to small teams. They are great for certain aspects of products that are critical. Test do slow things down because you end up maintaining two systems which for a small teams simply isn't practical.

@CodyEngelCodes

Жыл бұрын

It can certainly depend, if testing is valued then the tests themselves become easier to write because everyone is bought into writing testable code. If it's not valued then it becomes more difficult.

@BW022

Жыл бұрын

Why would team size have any bearing on unit testing? If you have two coders, their project is presumably much smaller than that of a project with six coders. Thus, you have 1/3 (or less) units you need to test. I've been on two person teams where we unit test each other's code. In fact, I'd argue that smaller teams need unit testing more as they have less free time to debug, push new releases, and deal with issues the bugs caused. I'm also not sure why you specially have to maintain two system for unit testing or why that is a problem with modern tools -- Git? Sorry, the application and its purpose is the key thing which should determine if you need testing (of any kind and how much). If it's a mobile game used by 50,000 people and developed by 20 people, it may not need testing (other than for financial security). If it's a banking app developed by two people in their basements... it needs a lot of testing.

@jamesjones2212

Жыл бұрын

@@BW022 Larger teams incur more complexity, more opinionated approaches, more skill differences etc. Smaller teams with skilled developers have a more clear, concise understanding of each others work and skill level than say a team of 5 -10. Ergo testing is needed more so for larger teams and larger systems. What i meant by maintaining two systems i'm referring to writing code and updating 2 systems and maintaining those code bases. For example you write code that adds to an existing feature, once that's finished even taking a TDD approach you will need to update your test cases to handle various changes, and thats assuming you write perfect code and some adjacent feature doesnt break. Lastly, yes that is correct the type of system being maintained certainly merits testing more than others.

@BW022

Жыл бұрын

@@jamesjones2212 I don't see why larger teams having more complexity means smaller teams don't have to unit test. All that appears to mean is that the smaller teams should be able to create, test, and fix quicker. Larger projects mean more testing and possibly more overhead with testing, not that smaller teams don't need it. I still don't see how you don't have two code (or more) sets with any sized team. Development, test, prod. Maybe you can skip test. Team size should have nothing to do with testing. It may make it easier or harder, but I fail to see how having only two people (or gasp one) means you don't have to unit test. I can't imagine how the type of system isn't the sole factor (any) testing? If something is worth testing, it's worth testing regardless of the team size, tool, cost, time, etc. If it's banking software developed by two, ten, or twenty... it's either worth testing or it isn't. If you need to factor in risk, liability, loss of business, being sued out of existence, etc. that's still on the software.

@jamesjones2212

Жыл бұрын

​@@BW022 Team size certainly has a lot to do with it if you only have a limited budget and are under pressure to ship code... You dont always have the luxury of a well groomed testing suite. You are not taking into account monetary constraints and i've experienced first hand as a solution architect if i'm given 2 developers the last thing i want is for them to spend time writing test when we need to get code shipped. Test writing absolutely incurs time and eats into sprints. I'll tell you a secret about silicon valley there is a reason they say move fast and break things because thats sometimes what you have to do and that doesnt involve TDD. Personally when I am working on a project and we have time to carry out TDD style testing i'm all for it. Its not however always a luxury you have in every situation. Its not just solely based on the type of product its based on how much of a burn rate you can afford over how much time you have...

about 10:00 - if you have code like this, i don't see how you can write good unit tests for it

Linux kernel, doesn’t require unit tests! Try unit testing a kernel! Especially for hardware that’s new, there’s not even a Vm that mimics the hardware. It is tested and profiled end to end. Unit tests are pretty useless because what are you testing? A stub of a piece of hardware you call from a kernel mod that’s then not running in a kernel (because unit tests shouldn’t be coupled). And how often is something seriously wrong in Linux kernel???? I had one issue that a unit test would’ve also not caught. That was when the went to 2.2 kernel and they change the SCSI motor on times from 20 seconds to 10 seconds and my disk didn’t spin up in 10 seconds, and my system was dead in the water. I just looked at the code (first time ever) just changed it, no tests and done!

@CodyEngelCodes

Жыл бұрын

Maybe that's why Linus needs to be so heavy handed with his reviews.

@CallousCoder

Жыл бұрын

@@CodyEngelCodes you need to be heavy handed when your software runs on billions of devices from the smallest to the largest. You think they aren’t heavy handed in aerospace? Where also unit tests are not the home standard but integration and end to end tests.

Not all opinions should be voiced, and certainly the one from Theo is rather misleading. When you only work on greenfield projects and change companies every 1.5 years, you are likely to develop Theo’s idea of not writing tests because by the time the project starts to stink, you are no longer there to deal with the consequences of your untested and poorly built code. It’s all fun and games until the software that controls a pacemaker, a car, or a plane crashes because of a bug easily catchable by unit tests because the engineer didn’t want to be “blocked”.

@CodyEngelCodes

Жыл бұрын

Whoa whoa whoa, I change jobs more frequently than average but one of my rules is "don't be that guy that shows up on a gitblame and everyone hates them". Of course I don't know if what I do has helped keep me off of that list, but that's the motto I try to live by 🤣 ...But also agree with your comment.

@none_the_less

Жыл бұрын

@@CodyEngelCodes Hey man, I do too, that’s how I advance salary wise. My point was really about the devs who never saw the impact of poorly written code.

@CodyEngelCodes

Жыл бұрын

For sure, that part of my response was more meant as a response. Your comment was spot on.

do we need 100% coverage with writing our unit test ?

Do you have a dedicated tutorial about unit test? If you have not, then you should before you reviewed this guy! There are many resources, but there isnt a one which is more clear and states the best practices. Perhaps instead ranting about how this guy is wrong, you could have helped people to write correct unit test cases. If possible please publish a course in Udemy with python unit test!

I don’t see value for unit tests. My units are generally so small that I can test them (as you do anyways during development) by hand. And then since the are tiny stand alone functions never need to be touched again. Now integration and end-to-end tests is where the real value is. There you integrated with the unknown crap from the outside world. With the ever growing problems for network latency and reconnect issues etc. The I simulate and they are HARd to simulate. But that’s where the real value is. The units of work are trivial, it’s the edge cases especially on exceptions where the real challenges are. I don’t care if a stub gives back a person record the way you “think” that api does it. You may as well test your own structure since you based your stub on that. That’s like the Pfizer being the main sponsor of the FDA. Now actually connecting to an api or database is the real test. But that’s integration ans systems testing. The only time I tend to write a test is for a public function that has complex business logic. Private function testing is utterly useless as the public functions should solely use those. And I rarely have bugs! And the things I create(d) are relatively complex. And ironically I’m the one who finds the most cases where things (can and will go wrong) unlike my unit testing colleagues that never seem to find any issues because they don’t properly test outside of that. And again the issues are in the real world. If you can’t write a simple api or a parser and test each small individual function as you are developing then you probably also don’t see the edge cases and security (always the biggest problem) issues on the horizon. Uhmmm make sure that nothing goes wrong when you got to prod! That’s the philosophy I have. And indeed unit tests aren’t a safe net they are a bike helmet they can help but on 99.9% of the cases you ride on safe roads and nothing happens. It’s actually more often that accidents happen because of bad roads and bad fellow drivers. And your helmet didn’t do anything to prevent that crash. Bike helmets are good for newbies learning to ride after that you rarely fall. And when you do it’s not because of your fault!

@CodyEngelCodes

Жыл бұрын

I used to test all of my code with a lab coat, but then people looked at me funny so then I started writing them like a normal person.

@CallousCoder

Жыл бұрын

@@CodyEngelCodes I like lab coats 🥼 I wear one when I do the development of the integration testing and E2E. Sometimes really going as low as preloading libraries that actually inject the test values. And sometimes (although not recently) even create hardware to physically test certain aspects. That was really fun! Last time was for a jail, to check if locks are indeed physically locked as well as the doors being shut. Apparently you can lock doors and not close doors and have a massive security hole, who knew 😉

You write a unit test in 20 seconds?! That I wanna see 😂

@CodyEngelCodes

Жыл бұрын

Once things are setup it's not that difficult to write tests. Maybe 5 minutes to get the initial file setup and then from there pretty quick to add on new ones.

@CallousCoder

Жыл бұрын

@@CodyEngelCodes but what do you test that you couldn’t have see with a single debug step? That is my point. You step through your code with a debugger and profiler then you know if it behaves correctly especially small functions like fetch data from a source (which is actually an integration test a mock is mocking the real world complexities that matter) But during the development of that function you see it work and see how it behaves and you don’t touch it anymore. Except complex business logic I tend to write tests for because laws and politics are inconsistent and messy they change they actually are sometimes overriding each other.

How the hell dude deals with regressions, 90 percent of errors are regressions

I pity Theo's users having to constantly discover bugs on prod.

@CodyEngelCodes

Жыл бұрын

😭😭😭😭😭

"Good solid meaty once" seems like a oxymoron

@CodyEngelCodes

Жыл бұрын

They're good, they're solid, and by golly they got some meat on dem bones!

That guy is someone who has never experienced the process of writing tests from the required behavior, and then implementing the behavior. He seems like the type who failed upward into his position.

It’s arrogant and ill informed to not write quality unit tests. Fixing production issues that could’ve been prevented is often a stressful and expensive exercise. Not to mention that whoever is paying you to build the product will not be impressed by the amount of interruptions or downtime or worse they will harbor a sneaky suspicion that you don’t know much or dont care. Theo needs to educate himself.

Not having to write the tests allows you to spend all of that time breaking the codebase. When you break the thermometer, you become less scared of the fever.

@CodyEngelCodes

Жыл бұрын

Very true, and then you can spend more time fixing the codebase!

@Power2All

Жыл бұрын

@@CodyEngelCodes Or make it so you don't need to, unless a huge change in programming style is introduced, which doesn't always happen... Well, except for Symfony in PHP... -_- Rewriting it from Symfony 3 to Symfony 5 was a horror, but most of it can be copy/pasted. Rust, I love, since it tries to keep changes to a minimum.

☝️ 𝓟Ř𝔬𝓂𝔬𝐒ϻ

Half of the comments that you make about his claims completely ignore the point anyway. To preface, I don't actually hate TDD, I just don't think prescribing a solution to a problem as fact is ever good. "[Unit tests] actually speed you up because if you only write tests that make the code pass, you're not actually gonna like overengineer things." If you actually at least try to understand the important pieces of the software you're writing and what the big picture looks like, then you'll know what is truly priority, and you might actually value not wasting time overengineering. The idea that I can write all of the necessary tests so that somebody else can understand what functionality it needs and doesn't need seems like a pipe dream to me. "As long as what you write doesn't break other things." Yes, tests make for reliable code. But, if you really wanted reliable code, it would be written in a language that allows you to better define when something is actually allowed to change. Obviously this costs more than writing javascript, but writing tests for it adds the cost right back anyway and probably doesn't solve the problem as effectively. High level languages exist because the software that uses them doesn't physically harm anybody if it breaks. I'd argue it should be expected to break, and it's faster to fix anyway. "What happens if a bug is identified at like 8pm?" If you're not hiring people to fill all of the time slots, then this will happen regardless (even though you boldly claim that bugs will never exist at 8pm in a TDD environment). His point is that if you spend money on good developers and creating a good workflow, then your company might not take 6 months to produce something that should have been produced in 3 months and piss off shareholders, not that bugs won't go untouched for a day while developers are at home. -- I'm aware that not testing might lead to a longer turnaround, but if that is a risk your development team is willing to make (And you actually ask them what they want before laying guardrails like TDD), then they are probably good enough developers to get it done in a couple months and not suffer the fate that you'd argue is inevitable. "How are your engineers less scared though?" I know I am certainly scared of writing double the code just to prove something to myself that I could have in a main method of a sandbox project if I really wanted to. Tackling new problems is important. If you allow your developers to fiddle around for a third the time it takes to write a test (Obviously they wouldn't have tests to ease their mind though and the same code will be thought about more than once), you'll probably see that you don't need half of the people on your team because your developers actually start to learn about all parts of the code base, instead of the sliver they're required to make changes to and accepting the rest as black magic because it lights up green until it doesn't. "The point of unit tests is not to catch every single bug, it's to document how the code should work, what the behaviors are, and create those safety nets so that you can refactor the code easily" Why would you claim that bugs will never exist at 8pm in a TDD environment then? Also, understanding the correct behavior makes the code possible to refactor, not easier. Sure, I'd need to do a bit of discovery for myself without tests, but that's how I will actually learn to speed the process up. "That is actually what you want to with code..." in response to cementing code in place by using tests to validate that it will never break because nobody wants to think about it again I don't agree with this. I don't think there's ever a case where code should be viewed as unchangeable. There are plenty of frameworks that work flawlessly and perform great, and many of them could completely rewrite their entire infrastructure and get rid of thousands of lines of unnecessary bloat. Plenty of frameworks have done it and still will do it for little to no benefit beyond having nicer syntax. And, even if you've written the same codebase in different ways a hundred times, there's still probably nicer ways to complete the same task. Completely scrapping old designs and reimagining them is sometimes key to unveil a good developer experience.

@CodyEngelCodes

Жыл бұрын

I can see you are very passionate about this and it seems that your perception is more so about the individual writing the code as opposed to others that will need to read, maintain, and update the code. I don't work with JavaScript, I primarily work with Kotlin which has plenty of ways to model things in such a way that minimizes the tests that need to be written. Yet I still write unit tests. I do this because once I merge my code into the main branch that's not the end of it, if it was then we would never smoke test applications and yet we do. Code costs money to write initially. It then costs even more money to maintain and manager over the months and years that it exists. Sure you can write the code really quick and look great to management while shafting your coworkers with taking forever to update the code you wrote. I'd recommend looking into how much time it takes you to complete a task over the lifespan of that task. Do one where you don't write tests and do another where you do write tests. I'd imagine the former will go quick until you need to manually test things several times. The latter will feel like it's going slower until you only need to manual test things a handful of times. And one of the riskiest parts of software development is changing code after it has been written. There could be subtle behavior that you don't realize exists which can lead to bugs that aren't easy to find until it has been released to customers. So anytime you can avoid changing code, you are de-risking the work. If you follow SOLID principals then it's actually not that difficult to adhere to this, yes you might change a couple lines of code to update dependencies but that's really it.

Calling himself an engineer and not testing... what engine is he working on ?

@CodyEngelCodes

Жыл бұрын

A pretty neat live streaming platform -- while I disagree with his testing philosophy I do think the platform he's building is neat.

It's funny that you mentioned "weird straw man argument that he is building up" . All of theos opinion videos a filled with strawmen and other logical fallacies. Often times he will say do something because xyz does it. In one of his videos he even goes so far as to make an entire montage of famous people endorsing his opinion, despite it being not such a great opinion.

The problem I see is inexperienced engineers wasting time testing code that should really just be refactored. If the code we were testing was a black box that would be fine but the kind of "unit" testing I see cements front end components in place when in the long term more fundamental changes in the component tree and structure are called for. I think some less experienced devs are just too eager to nail down their awful first drafts of a solution with a gigantic test suite that will be useless when the inevitable refactor comes. If you have a good modular solution, go ahead and test it. But if not, maybe reconsider your solution.

@David-gj6dc

9 ай бұрын

In other words, bad and low value unit testing is what I see a lot of

It's not a bold statement. Claiming that it is a "bold statement" is just an attempt to legitimize his position. "You disagree with me? Oh, you must just not be 'bold' enough to get it." Meta doesn't write tests for one simple reason: they want to hire a metric sh*t ton of devs. When you need to hire a sh*t ton of devs you are going to be scraping the bottom of the barrel, and pulling out a lot of people like Theo who are not trained, not educated, and are not thoughtful or mature about what they're doing. They don't see value in training devs or developing a good culture around testing because their devs are very transient, changing companies or moving between teams etc. They develop a "hack it quick and dirty" culture simply because it fits their business model and operating conditions. How even would they develop a testing culture? You absolutely cannot develop a good testing culture by simply mandating tests. The only thing worse than no tests is mandated tests. Developing a good testing culture requires hiring a lot of thoughtful, mature engineers, who can agree on their philosophy and methodology of test. You can hire younger people certainly, but the goal would be to indoctrinate them into the culture through things like pair and mob programming. This is simply not how Facebook operates. They have so many engineers, they cannot give the individualized TLC to each kid necessary to develop their engineering skills. This is becoming more and more the norm. With developers in as high a demand as they are now, you're gonna get a lot of script kiddies like Theo; boot camp grads essentially.

Not doing unit tests, encourages devs not to produce with modularity. Theo has made a few statements that are harmful to our industry. He really needs some help from Uncle Bob.

@CodyEngelCodes

Жыл бұрын

Uncle Bob has says some things that are harmful to our industry but for other reasons, his opinions on writing clean code are really great. His opinions on diversity, a little misguided I'd say 😅

@ZwartCode

Жыл бұрын

@@CodyEngelCodes I can agree with that.

@SwimmingInSeas

Жыл бұрын

Yup, TDD improved my code so much it's crazy. You can usually tell whether code is well tested just by looking at the code itself - good tests enforce good quality. After seeing some questionable videos from Theo I checked out his linkedin - the guy has only held down one programming job for more than a year (twitch - 4 years). I don't get how someone with so little experience can go on youtube and act like an authority. But I guess that's youtube ...

@jordixboy

Жыл бұрын

@@SwimmingInSeas TDD is only for juniors.

@rockatanescu

Жыл бұрын

@@SwimmingInSeas no, tests do not enforce good code. They never did and they never will. All that tests to is allow you to verify in the specified behaviors of the system are unchanged, which then allows you to refactor code. The process of refactoring is what improves code quality and the tests are just a tool to ensure that you can refactor safely. It's not about bugs (other than regressions, of course) or driving design, it's always about refactoring. That's also why Theo doesn't feel like he needs tests: because he does not feel the need to refactor as in change implementation without changing the behavior and he's fine with changing code while also challenging the current behavior. This is very common for developers that have never worked on projects for longer than 2-3 years.

Theo is wrong on this one. Tests have been shown to speed up development, it only feels slower. Not only that, but once you write tests you will have more confidence in your code as it won't regress to a previous state Silently. I feel like Theo is the type of developer that prioritizes writing code, but not on quality or readability. He promotes Tailwind, a CSS framework based around ultra concise code that is easy to write, but hard to scale, then he does this too. Sorry Theo, get with the times.

Don't confuse 'unit testing' with 'testing'. Testing is crucial. Unit testing is for juniors, bad seniors or pussy-millenials. Theo just nailed it.

@CodyEngelCodes

Жыл бұрын

uh huh...

@dmitrykim3096

10 ай бұрын

Lol bad seniors are.those who think that they are too smart to write shitty code

Honestly, as much as I don't like writing unit tests, what Theo said is just so wrong on every level. He is just glancing over loads of issues and taking a completely wrong approach. A 7-minute turnaround on production bugs with no way to know that you didn't just introduce another bug. Utter nonsense.

Theo is wayyy too dogmatic

The amount of bad faith in this video is truly impressive. “The metaverse isn’t doing well so maybe they should write tests” lmao Every single example you give would be hard or impossible to cover with tests. If anyone here wants to see a better faith convo between me and a pro testing person, check out my debate on the topic with Primeagen

@t3dotgg

Жыл бұрын

“This is a very weird strawman he is building up” holy SHIT. Let me come on. Let’s chat.

@CodyEngelCodes

Жыл бұрын

The metaverse that Facebook is building is buggy, I'm assuming they are building said metaverse with code and so most of it can be covered by unit tests. None of the examples that I gave would be impossible with tests. And yeah, you were kind of building up this strawman, as someone who does write tests I also don't agree with code coverage at all costs.

@rpgonline300

Жыл бұрын

I guess the main issue with the metaverse is the core premise of locking up humans in digital realities.

@yourplayer5

Жыл бұрын

Saad that no further conversation is going on between you two. I would make another statement, and that is that you are both correct. Theo points out correctly that unit tests block you and that you need to know when to use them. 100% agreed Cody mentions that unit tests are a form of documentation and not to catch bugs in production. Also 100% agreed As always in software engineering, it depends on the project you are working on and I think in this case the lifetime of the product as well. I am just grateful that you can find different options online and learn from all of them😁