TDD

Рет қаралды 98,867

8 ай бұрын

Recorded live on twitch, GET IN
/ theprimeagen
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Kinesis Advantage 360: bit.ly/Prime-Kinesis
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/deeznuts

Пікірлер: 107

@Flameandfireclan 8 ай бұрын

“ADD (Anger Driven Development)”. The chat is spitting bars

@ristopaasivirta9770 8 ай бұрын

TDD allows me to dictate impossible tasks and leaves me more time to grind Path of Exile while the devs struggle to meet the specifications.

@diaaway 7 ай бұрын

As a developer i support that! PoE grindset is important, just please make sure your devs can grind some too! Ideally force them to aurabot.

@tharteon1866 6 ай бұрын

Oh yes, PoEDD, my favorite programming workflow.

@mhouney 6 ай бұрын

Felt that!

@dreamdeckup 29 күн бұрын

dangerously based

@jamsky1558 7 ай бұрын

TDD walks into a bar and asks for 1 beer, 9999 beers, -1 beer, #$y& beers. Customer interface walks into a bar and asks for the toilet. The bar is set on fire.

@j_stach 7 ай бұрын

Hahaha clever

@yungifez 6 ай бұрын

This is funny

@larryd9577 8 ай бұрын

TDD is not "write all tests upfront". It is "write one positive test for what you think it should return, then implement it". If you are wrong change the test and correct the implementation. I don't get the hate it receives. I really like having a set of checks, which prove me that nothing broke, when I restructured something or renamed something. It's like the OG CoPilot.

@henrikholst7490 7 ай бұрын

Re. "that was not real socialism"

@jamfin6644 6 ай бұрын

And when TDD fails to cover something unexpected, you can expand the test coverage.

@jeffwells641 6 ай бұрын

This is great until you don't fully understand the problem domain and so completely fail to write any tests for a whole category of failures that you didn't even know were possible. Building tests that can catch unknown unknowns is impossible. Building a working prototype that demonstrates the unknown unknowns is easy.

@larryd9577 6 ай бұрын

@@jeffwells641 if you dont understand what you should build, you especially shouldn't write any code at all.

@slotos 6 ай бұрын

@@larryd9577this just made a lot of people unreasonably angry.

@ShikaIE 7 ай бұрын

Not only you’re gonna feel awful integrating them, you’ll also waste a lot of time rewriting tests when you realise the implementation is not gonna work when integrating. My workflow for doing something new is always quick poc with quick codes, then refactor with TDD.

@taestott 7 ай бұрын

Ever since Return To Office one of my coworkers coined the term "Location Driven Development" 😂

@robertluong3024 8 ай бұрын

I like outside in TDD where I start with an e2e test and work inwards. That being said, yes, it mainly works when you know what you're doing. For exploration and experimentation, you're spending much ado about nothing.

@natescode 8 ай бұрын

Agreed. Tests can't prevent bugs the developer didn't think of before hand. They're great for prevention regressions.

@RichOrElse 8 ай бұрын

TDD is a habit, if you are not used to writing good specs, it will slow you down.

@CalifornianViking 8 ай бұрын

Automated unit tests are great when you have something to test. TDD messes with the creative worflow when there is no interface specification.

@CaimAstraea 7 ай бұрын

I kinda gave up. The specifications keep changing and ended up spending more time fixing tests every day than doing actual work.

@ward7576 7 ай бұрын

Sounds like the guy was describing BDD (Behavior Driven Development) with that "exploration of the interface". It's very tough to even do BDD if you don't have your plan ready for 90%, TDD also requires you to understand the domain before you write anything.

@relativisticvel 7 ай бұрын

TDD is good for fixing bugs. Make a failing test then fix the thing, so you know you are actually fixing what you think you are.

@sorcdk2880 7 ай бұрын

Another problem with TDD is that it kinda forces you to built things top-down, which has its own issues. Sure designing an architeture generally works better in a top-down approach, but I find that actually writing code and solving problems tend to work much better in a bottom-up approach done after your top-down designing phase. That you generally know what kind of problems you need to solve from the design phase, so the pieces you built bottom-up as solutions to those problems are much more adaptable to the changes to the design you are very likely to need to do, whereas if you built things in a top down way, then the form of your solution processing components are more of "I want something that makes this line nice", which puts a lot of extra form and restrictions on the inner part that really did not need to be there and which adds to the complexity of figuring out and writing down the solution to that given problem. It is also much more prone to just needing to be deleted when something goes wrong. Think about it this way, when building your structure of components and putting them together they work kind of like a tree, and there is a far greater amount of end components than there are big nodes putting them together (with something with more than 2 branches per node), and in a top-down approah a failure to build one of the end points cascades back to its parrent node, as it needs to come in a different format, and possibly cascade even further up, and most of the children of such nodes will no longer work either, because the needs from their parent have changed so they no longer fit. This means that just one failure can cascade into a ton of code that needs to be reworked. In a bottum-up approach a failure generally happens more often at the nodes levels or a node needing something different from its children, but in either case you have fairly isolated escalations, because it is either just that node or the problematic child that needs to be rewritten. This means that as the problem you want to solve gets larger and larger, then you get a larger and larger chance that you have to throw more and larger parts of your code away when you eventually hit a problem. With bottum-up construction, you can keep such things down, and it becomes more feasible to attempt to solve larger problems. Now you could do TDD on those smaller components, but the trick here is that for these components the actual interface absolutely does not matter, as it becomes whatever is the most convinient to link the different parts of your problem solving together. This also means that TDDs fixing of that interface puts in extra constraints that barely have any reason to be there in the first place. Overall I find that it generally makes the most sense to do TDD when you have an outside defined interface (such as when the jr gets told they need to deliver this thing by the seniors or an architect), or in other special situations when someone does have good knowledge of how to structure the problem, such as when mentoring someone, where the mentor can guide the tests and interface to make the mentee explore the posible solutions, but guide in the right direction by that early setup. In fact I find that the fact that I can use it that way to mentor other people also mean that that early form of interface and test lockin means one would also lockin how they think about the problem, which can then create a host of issues later down the line. This is how that problem with needing to understand the problem domain and the interface that primeagen talks about comes in, because it is especially problematic when you have problems there, because it is the likely flawed understanding of those that gets locked in so early and becomes much harder to move away from, if you use TDD on such projects and at full scale.

@vrongmeal 7 ай бұрын

Not here to defend TDD, but it’s better (99% of the times) that you have something good for testing compared to something thats way hard to test

@diegolealco 7 ай бұрын

TDD is a methodical and structured way of solving a problem; it does not interfere with creativity, it helps you articulate it. The byproduct is a really good suite of tests which will end up saving you countless hours of work. If lack of direction doesn’t kill a product, lack of good tests definitely will.

@hereallyfast 7 ай бұрын

It's such a bad take. I hammer out features so much faster and so much more stable. Whenever I do TDD. You can work through the problem with the tests. I don't even think it's test driven development. It's regular ass development. I feel lost w/o it

@cooltrashgamer 7 ай бұрын

What do the tests do for you that you couldn’t just do without them, what’s the difference between writing a test for a stub of a function that doesn’t exist, instead of just writing the function? If you’re going to mess up the design on your first try (which you probably will if you don’t understand the problem/domain which is being argued here), then you’re going to have to probably delete all your tests when you realize your implementation sucked.

@DM-fw5su 7 ай бұрын

You are forced (in a good way) to decide what the function is going to do and how it interacts with the consumer before you write a single implementation statement. Now you have an elegant external API, you are free to make the first attempt at implementation as awful as you like in order to achieve the nice external API. Then don't forget the third step, you can refactor and cleanup internals. So many programmers just want to get on with solving the how to implement the internals in an elegant way first time, that the resulting external API is horrible, but is needed that way so they can keep the internal elegant. When that was never the task, the task was an elegant external API at the expense of inelegant internal detail when compromise is necessary. TDD also focuses the task of only doing that which is necessary to pass the test, so many programmers want to meander into areas of elegant optimization with the internals which again often misses the real task.

@cooltrashgamer 6 ай бұрын

@@DM-fw5su I can't tell if I already responded to this. But the argument is _specifically_ in cases where you don't know the domain of what you're trying to program. In those cases, you don't _know_ the API boundaries, you don't know the structure, you don't know the functions you have to make, you don't know what should be extracted, you don't know what's going to be repeated, you don't know how things are going to interface with each other. Unless you are a savant, even people like Carmack, Jeff Dean, and other legendary programmers will tell you that they typically get it wrong on their first attempts, and they just build it bottom up. Once you're aware of the structure and problem domain, you're free to throw away the code and start over doing TDD, but your ego is really high if you think you can work in a new complex domain and get your TDD stuff right the first time, odds are 90%+ of the tests and code you write will be trash, and you'll have to do it all again anyway. Save yourself some development cycles and brain cycles, and just figure out how to wrangle the data and domain and then go back and do things the other way. Of course, this _doesn't_ apply to working on domains you're familiar with. If you're just doing CRUD web apps that you've already made some variant of before, then sure, TDD to your hearts content.

@eamonburns9597 8 ай бұрын

What I have been doing recently is 1. Write a function that works (barely) 2. Write tests that the (barely working) function passes 3. Write more test cases for the function as i come across them (they fail) 4. Rework the function so that it passes the new tests (And what I mean by "barely" is that there are probably a lot of corner cases that will break it that i don't know about yet) So I guess that steps 3-4 are technically "test-driven" because I am writing the failing tests first, and then fixing them

@JustMe-lp5td 6 ай бұрын

I think people misunderstand TDD. like how can you know if your code works unless you run it? tests are just there so you know it works without having to build the whole system, so you can iterate faster. Then you build the whole system XD.

@Smakenzi 7 ай бұрын

TDD is a concept Uncle Bob built his company around

@orlovskyconsultinggbr2849 7 ай бұрын

no, no, you use TDD as design tool! IF you cant came up with good design its up to you not a problem with TDD

@jonathansaindon788 7 ай бұрын

What happens when you make the test after the implementation is that we often don’t have time to do it correctly. Also, TDD forces dependecy injection in your architecture.

@PaulSebastianM 8 ай бұрын

Dude, you should test like you are actually using the code you wrote, not like "in a test"...

@mohamaddelkhah 7 ай бұрын

"You're an ignorant interface" thank you very much!

@PierreThierryKPH 7 ай бұрын

Dude, so many of us experiment the opposite: when we're not sure where we're going, TDD is just great. And we basically never end up with a bad API, because we put in the tests the kind of calls we would make in production code. Are you even doing TDD‽

@T1Oracle 7 ай бұрын

The biggest problem with TDD is reliance on libraries that said "forget testability." Which is a surprising number of libraries. Regardless, it's not for everyone. However, if it's for you, then you can use it anywhere.

@bioblade87 7 ай бұрын

TDD on the back end. Give the QA team the front end testing lol

@daemonginger2438 7 ай бұрын

He said "interface", not "user interface"

@RadicalGaming1000 8 ай бұрын

The full video was great. I liked prime's take

@markjrcolin1210 8 ай бұрын

I feel like I’ve wandered into an area of KZfaq where I’m hearing things about stuff that I’m wildly ignorant on. For example, I have no clue what “TDD” is, or what the “interfaces” are referring to. All I know is that this lad sounds like he really knows his stuff. Guess I better watch the full vid for proper context, eh?

@TehKarmalizer 8 ай бұрын

If you do any programming at all, it would be helpful to understand these concepts.

@invinciblemode 8 ай бұрын

If you’re lost here, the full vid will still be of no help haha

@markjrcolin1210 7 ай бұрын

I know nothing of programming. I took an intro coding course at university, was learning python, and literally shattered my laptop screen in one punch out of sheer rage over failing at making functioning lists within three days. The lists weren’t meant to serve a purpose, they were just meant to function in the most basic ways. I’m what most would call: “computer inept”. Word and PowerPoint and a few sketching apps are all the productive programs that I can operate competently on a computer. And my typing alone is a dead giveaway on how I don’t know computers😅

@zamidare9038 7 ай бұрын

@@markjrcolin1210i love c then i started to learn python this year and i love it now. when java was being explained to us back in college, it looked hard but i like to learn more programming.

@TAP7a 7 ай бұрын

Interface: set of ways that a you can interact with some existing thing, in programming often a set of functions, objects with functions, or parameters that a programmer can use to retrieve data from or write data to some service like a web service or an operating system TDD: Test Driven Development a paradigm for software development where tests (comparing actual output to expected outputs) are written before implementing the actual solution. Proponents say it does things like clarify requirements precisely, drives increased test coverage and therefore improves reliability. Opponents say it hampers the creative and logical flow of how code is written, and as this guy says it only really works well in extremely high-information scenarios. Alternatives include Agile and Waterfall

@andreaspokorny3089 7 ай бұрын

Yes if excel at TDD you build little small testable fragments. Only with luck you get something that concise/useful/maintainable/... Or you have experience with solving the same thing - if that is true you might not need TDD.

@ThePremez 8 ай бұрын

How can you start writing code without knowing the interface first?

@LPHayes-pw1gv 8 ай бұрын

You have a rough idea of what u want to build then you build that rough idea and from there you refine it to a more finished product.

@GuillaumeLudwig 8 ай бұрын

Yes and refining this rough idea is exactly what I use TDD for.

@henrikholst7490 7 ай бұрын

Everything should be built top level down, except the first time. E.W.Dijkstra.

@cooltrashgamer 7 ай бұрын

@@GuillaumeLudwigI think Prime’s argument specifically seems to be where you don’t understand the domain of the problem you’re trying to solve, you aren’t aware of when/what/how the data transformations should happen, what should/shouldn’t be abstracted, what should the final interfaces look like to be used. I think specifically the argument is that TDDing in an unknown domain is going to be a waste of time because there’s > 90% chance that you didn’t have the insight to design things properly on your first try, TDD or not. So he usually suggests a “spike project”, where you just get a super crude MVP of the feature you want to build, KNOWING that you’re going to throw it away. You make the MVP, and now you’ve gained some domain knowledge, you can spend some time planning now on what you think would be a clean design, and maybe even TDD the feature from that point on.

@GuillaumeLudwig 7 ай бұрын

@@cooltrashgamer thank you for this, I didn't saw it this way. It makes sense. In this particular scenario I would go without TDD as well. At work most of the time we know what we are doing beforehand. We have a technical analysis of the task and we create a checklist with items that "prove" the future development will be ok. We know how to test it from the "user" (not always an UI) point of view. Then writing tests is really easy.

@elobiretv 7 ай бұрын

Sounds like you are just doing TDD wrong if you are designing the interfaces to fit the test...

@SamyarBorder 7 ай бұрын

Agony Driver Development 👍😂

@awmy3109 7 ай бұрын

Facts.

@ordep1132 7 ай бұрын

Explore the interface. Implement it with TDD.

@cleverclover7 7 ай бұрын

you're both right

@drj9403 7 ай бұрын

Agree 1000000000

@Krapvag 7 ай бұрын

TDD in practice usually means "don't forget to write the unit tests when you create a merge request"

@Templarfreak 7 ай бұрын

i feel like this is not really the problem, here. the problem with unit tests is that the entire point is to save you time but if they arent doing that then they're totally worthless and there is a huge problem of unit tests wasting people's time so often and so frequently all over the place. they are just like any other tool. you *cannot* rely on them solely. you can _use them_ to _help you_ do what you need to do, but they are *not* the solution to everything and you need to use your own judgement sometimes.

@ivanjelenic5627 7 ай бұрын

Based.

@carneios08 8 ай бұрын

I tried doing TDD in my last prototype and it felt awful. It felt like the tests were driving the architecture and design patterns. Building for the user experience you want to create should be the focus.

@mzyil 8 ай бұрын

tdd becomes viable when you relax the rules and for example allow yourself to go back and modify tests.

@Salantor 8 ай бұрын

It seems that you are not supposed to do write tests when prototyping, but only when you have something of an idea of what you want to make.

@scvnthorpe__ 6 ай бұрын

In fairness i do whiteboard a lot for my serious projects

@Boxing_Gamer 6 ай бұрын

It could be useful when making simple API or simple websites, but I don't think you can code GTA 6 in it.

@davissp14 7 ай бұрын

100%

@cammiller7686 7 ай бұрын

Prime is really off the mark . I’m shocked he doesn’t practice the red green refactor cycle

@mcp866 7 ай бұрын

I think this is more so a problem with what you're testing. Don't have a perfect idea of how this thing should be integrated? *That's* what you should be testing.

@martinbecker1069 7 ай бұрын

BDD > TDD

@peachezprogramming 8 ай бұрын

Agreed, TDD is great when you actually understand the domain

@eamonburns9597 8 ай бұрын

I would really like you to talk to Dave Farley, he is super into TDD and really seems to know what he is talking about, but your points make a lot of sense too. I would really like to know what his response would be

@henrikholst7490 7 ай бұрын

I feel TDD is the next OOP like bastion to fall.

@macchiato_1881 7 ай бұрын

Always has been. Designing your test based on actual implementation details feels more right.

@sorcdk2880 7 ай бұрын

I remember being told "all these supposedly good practices have turned out not to be good, except TDD", or at least something along those lines.

@byronjones5902 7 ай бұрын

This guy’s problem with TDD rests with the fact that he’s REALLY good at his job. If you are an expert developer, TDD isn’t for you. At all. I love TDD - but I never practice it personally. I have a jr developer, and TDD has proven to be a great tool to ensure that he wrote what I told him to write. And that’s what TDD is good for. Its a normalizer. It’s the answer to the question “how do you make a developer that isn’t very good at problem solving yet functional in the short term?”

@SlowAside5 4 ай бұрын

TDD is still great for expert developers. When doing TDD, it’s not uncommon to gain insights that result in simpler code that might not have occurred to you otherwise.

@TheBlackmanIsGod 8 ай бұрын

WTF IS TDD

@tomatopotato4229 8 ай бұрын

Treat Driven Development. If your programmer did a good job, they get a treat.

@erastvandoren 8 ай бұрын

TDD is the stupidest thing on Earth.

@noredine 7 ай бұрын

Titty driven degeneracy

@AregGhazaryan 7 ай бұрын

tf is tdd

@Helvanic 7 ай бұрын

At some point you're going to have to stop spitting this bullshit. TDD is useless when you totally understand the problem and the interface. If you already know both, what's the point of writing tests before ? Makes no difference. The whole point of TDD is to help you design the interface. You can like the technique or not, that's up to you. But don't spread misinformation.

@genericdeveloper3966 7 ай бұрын

In the start up world TDD is rarely used. I haven't used it on my app, but I do have a test script of the most important features to the end user (only about 20% of the codebase). If my product is successful, sure we can start thinking about TDD. Until then I will save money.

@erastvandoren 8 ай бұрын

Nobody does TDD

@gge6021 8 ай бұрын

tdd sucks there is no way around it. Just totally uneccesary mental overhead and if you actually think it is useful your decision making in general is in big question and the ability to make user experience focused actually useful so to say "good" software is far gone to the toilet.