Why Would Anyone Hate TDD? | Prime Reacts

why people hate tdd Dave take it away customer development is one of those things that you seem to either love or hate actually that's not really been my experience I'm a tdd lover I suppose if you can love at all I'm certainly value entirely my experience is rather being that the majority okay so I feel like one and a half is a little fast for Dave okay let's go let's go let's start off at 1.25 let's try this again okay we're gonna we're gonna try this again here we go why people hate tdd test driven development is one of those things that you seem to either love or hate actually that's not really been my experience I'm a tdd lover I suppose if you can love at all I certainly value retired did I just hear I'm not trying to make any stamp judgments about Dave but did he just say the saddest thing in the universe I'm a tdd lover I suppose if you can live at all if you can love at all uh okay What is love baby don't hurt me you value me tightly my experience is rather being that the majority of people really like test doing developments once they've seen it working but getting people to try it is often very difficult indeed there are lots of people though that do profess to hate it and I saw so just so you know I am somebody that hates tdd do you get like a type one in the chat if you love tdd type 2 in the chat if you hate tdd and then I'm sure you guys will also fill it with various other numbers describing that you don't really care I'm I'm in the hater Camp well I've actually hate or love because I see a lot of twos and now I'm starting to think you guys love tdd that can't be real that can't be real did I forget two equals hate okay I was like damn I misjudged my audience a lot I guess I'm a Loner on this why yeah Twos for hate okay I just thought maybe I I thought maybe I had a really odd opinion here for a second okay um let's say so so instead of me giving my judgment let's do what I think is a better move to do in general let's hear a good argument for why we should enjoy tdd and then let's take that argument and can we apply our opinion still or or have they defeated us right let's try that and others recommend it I think they're wrong in this and missing something that will improve their skills significantly if they adopted it but me saying things like that is the sort of thing that annoys them and I can kind of understand that too someone like me just repeating you aren't doing it right if it doesn't work by the way if if your answer is you aren't doing it right and that's why it doesn't work I mean that means tdd falls under I mean it falls under Scotsman communism now tdd like it's just you don't want to be in that category you don't want to be a Agile development you don't want to be in the category of of you're just not doing it right good enough so can we tackle this through a different angle okay let's take a look at some of the common objections to test driven development and address them without only me saying you're doing it wrong or at least try to continuous delivery welcome to my channel if you haven't been here before please do hit subscribe and if you enjoy the content today hit like as well let's start with the definition so that we're sure that we're all talking about the same thing love it because one of the ways that people do tdd wrong is not to do it at all okay driving the code from tests so red green refactor red write a test see it fail Let's test the test and makes us focus on what we want the code to do green make the test pass this finds the shortest route to stability in the form of code with a passing test and refactor tidy the code and test to make them beautiful elegant simpler and more generic whatever it is that we want of the code so so one thing I immediately dislike about this is that I find that so maybe I Define the word unit incorrectly maybe I Define it not the way they do but for me a unit is always comes down to just simply a function I'm really testing a function and in and out a black box that's what I consider a uh like a um a unit testing or yeah unit testing Sorry I don't know why I got so mixed up there black box testing single function testing to me that is unit testing in of itself I want that you you want that shirt yeah and so when I see this red to Green I get that I totally get this it's actually the blue part that is really why I get most confused here you know what I mean because it's the blue part that causes it to be so difficult it's because when I go from red creating a test that doesn't create that hasn't been created to green and enjoying it often when I refactor it requires a wide range of changes right like I want to change how things are done maybe in its completeness and so at an integration test level or an end-to-end test level though that interface may not change but everything inside of it is going to change and so whenever I do this blue part I always feel like I become red not because I am uh not because I am somehow you know like failing or creating bad code it's because the shape that it was in is no longer even there anymore and now the functions that I was testing the black box that I was testing is completely different and so then I end up rewriting tests to reflect the reality which almost in some sense I actually write tests to give me green which ultimately gives me kind of like the big warning signs right which means that I'm now writing potentially synthetic tests that don't actually test anything but I've simply become something naughty right I've actually become something wrong yes I don't know what code I want until I start writing code then I go through a few iterations yeah exactly so this is this is like this right here is my argument against tdd in a nutshell which is I do use tests to drive development sometimes because I just need something that I can quickly test right if you have a program that requires you to go get data from a database and then it has to come back they have to go get it from another source and maybe that source is like some sort of big data source so it takes like seven seconds you know I'm just gonna I'm just gonna create synthesize or a synthetic data version of that just so I can test really really fast and make sure I have all the right state right it's just a little different so can we all agree that if you don't write the test first it really isn't test during development we can agree with that right can everyone agree with that if you don't write the test first it is not test driven development which I think he's 100 correct on I think we're both now perfectly on the same page because or else you're not letting the test drive the development instead you're driving the development and then coming back and doing something different anything else is just testing and that's something quite different with different goals and a different setting so let's say hold on someone saying fix some audio let's see uh am I just peaking on this system thus I'm getting picking on this here let me yeah I had this thing all the way up so I'll try doing this here we go sorry my bad my b the problems tdd allows us to bypass most of the problems with testing alone but they aren't the same thing at all this is such a common confusion that as a promoter of test room developments it's my impression that confusing test driven development with just testing leads us wrongly to ascribe the failure and problems of just testing to test driven development I'd like to say I'm a genius uh so here's the problem is that sometimes we listen to to videos and their volume people normalize videos to like absolutely just just Savage levels of lowness right where it's like they're whispering in and so I'm jacking my audio levels all the way to the tippity top just to hear anything so I guess that you could say that now I'm just saying you're doing it wrong again but I'd say that in this case it's more like you aren't doing it at all so that seems fair to me okay fair talk about this confusion and more in this video so do check that out after we finish with this one let me pause there to say thank you to our sponsors we're fortunate to be sponsored by equal experts trisentis transfig and Ice panel all these companies offer products and services that are well aligned with the topics that we discuss on this channel every week so if you're looking for excellence in continuous delivery and software engineering click on the links in the description below to check them out the other thing that I'd like to put on the table to remove as a distraction from this discussion is that test driven development is a skill it's not innate to anyone everyone who wants to do it needs to learn how did we just get to skill issue are we about is are we about to hit a skill issue I feel like I just got hit with a skill issue and he takes a little time and practice to get good at it not if not a long time but sometime even very good programmers aren't good at test driven development straight away that's a problem for test driven development adoption because if you try it for a short time or if you're only trying it because your teammate or your boss told you to you probably won't get to the good stuff or you won't be paying close enough attention when you do I suppose this is me saying you're doing it wrong yet again and I think that this is probably the real source of this criticism of people like me who try to promote the idea but I think that these two things are simply facts if you try to play before he does his analogy actually we'll let him do his analogy and then I'm gonna get I'm gonna I'm gonna I'm gonna render judgment onto him tennis or Paul or League of Legends for two hours you won't be any good at it and you probably won't understand what the appeal is if you play table tennis instead of tennis and then dismiss tennis you're not making a fair or reasonable comparison so let's look at some of the common okay I I understand his point yeah like you know I've used a lot of rust I've written a lot a lot of rust um I I I would put myself as fairly good at it I'm not great I don't know all the nooks and crannies of rust I don't pretend to know even the entire standard I I don't pretend to do uh you know like I'm somehow great at these things uh but ultimately what I see that is a huge downfall of rust is that it's hard right it's just simply a hard language and it has some it has some use cases that are really great for us right that just do a really good job fitting the language and then there's some use cases where it's like you're just shoehorning it in and it feels really annoying but we still do it anyways because rust is really fantastic and so I totally get this argument where you're just saying well hey it's because you haven't done it enough therefore you don't understand it this is effectively his argument he even agreed that his argument is that you're just doing it wrong the hard part about doing that is that this isn't just me with a specific language on a specific problem this is saying an entire way to write software overall is that there's some level that you have to achieve some unknown state where it actually becomes better but you don't really have like a strong way to prove that it's actually any better that's kind of what I'm seeing right now is that this is how I like to write software therefore it's the correct way to write software now I take a much different approach a little bit loosier maybe a little gooseier I I get it objections there are more clearly about test driven development itself first people often say that test driven development is too slow I think there's a real grain of Truth here at the time when you are writing the tests and the code it is slower certainly when you're just starting out there are several reasons for this though one is that tdd forces you to change how you think about solving problems and that's challenging and particularly I mean this is literally this is literally a rust argument right now I mean here's word for word making the rust argument here we go if you're an experienced but non-te Dev this definitely feels slow and painful everything is familiar but different enough to trip us up so we are in fact going slower I think as a result it's usually easier to teach test driven development to less experienced people they have fewer bad habits to unlearn I suppose it is literally the rust argument like 101. I've skied quite a lot since I was a boy one of my then teenage Sons wanted to learn to snowboard he was already a good skier so I thought that I'd give it a try too my son had had lessons and so we rented a board for me to go snowboarding with him as well and he showed me some of the basics I skied to a gentle slope sat down on the snow and switched to the board while I sat there looking at my feet someone sneakily tilted the mountain up and made it dramatically steeper and more dangerous while I wasn't looking the results were what you might expect and I returned gratefully to my skis after the usual kinds of things that you would imagine happening and the mounting regained its normal gentle slope again I think that this is the same effect as the experienced developers trying test driven development the difference it's got like a hair or or like a bug right in my eyeball I'm not sure what just happened there but I just went from normal mode to like really painful in a matter of seconds okay we're back in so is that test driven development offers real concrete benefits where as whether or not I chose to scale snowboard is really just about me having fun so right now I'm still on board where everything that has been described described up until this point is purely it's kind of this is pretty much the classic DX argument which is does it feel better for you then it's better developer experience tdd feels better for me because I can do it really well therefore it's good for me therefore it's good it's good developer experience you like good developer experience don't you you should do tdd right it becomes like this this like kind of like circle of argument right where you can't technically defeat it at any point because the initial the initial point is subjective and it just overlaps on top of itself so then it's just it's it's unarguable so I think that there should be a bit more of a professional skills focus when learning test driven development I may be hardlining this but I think that test driven development is always better than not and so learning it is a kind of professional duty of care issue the other more obviously commercial Advantage here is that unlike the snowboarding where when it feels strange and difficult progress really is slow in test driven development that is more of an illusion generally whenever I see someone say that there's like a professional requirement to be an engineer like they're the same people that want uh certifications usually uh uh I I find all those things to be completely irrelevant because the certification almost exclusively goes away within moments right within within just a couple years anything that you're certified on becomes irrelevant like the amount of java certifications that were largely available not too long ago are all almost completely not available uh just because it doesn't they don't mean anything so I I am still having a little bit of a hard time here following some of this customer development is like an investment of thinking the big savings come lighter after the investment has been made so it's a bit more work at the time when you are actually doing the investing at the point of writing the tests it feels slower to me too than just writing the code but it isn't because without the test to guide us we're more likely to make mistakes in the code let's slow us down and then spend more time figuring out our mistakes and fixing them which slows us down more probably filling up fiddling around testing the code manually which is way slower than simply re-running a test so there's definitely an inherent missing point or an inherent argument here which is incorrect uh I believe this is like a very concrete way of me arguing against this which is you're making the assumption that you can test bug free but you cannot write code bug free I've written bugs in my tests such that I have confirmed bad behavior I have written good tests that have confirmed bad behavior right like that's the problem is that you can't think like the reason why I write buggy code is because I can't think of every way the code May Fail if the code May Fail in an unexpected way I never wrote the test to begin with therefore it still fails the unexpected way in the end something about this is kind of like a cop-out to actually hey no matter what you aren't good enough that's just that we're also more likely to release Boogie according to production one one more thing I do want to state that if you don't have a lot of pre-written code already that you're testing often I also find it much harder to write declarative tests uh I try to always write my test as declarative as possible because I don't really want to have any like explicit stated like for Loops I really do try to avoid any for Loops because that almost exclusively you know every time I add more logic into a test I've just written something that's harder to maintain and harder to know when I've done something wrong or right and so when I have nothing it's really hard to write something that's declarative right because then you're right you're going to have to write some set of code to be able to produce all these things in kind of a declarative way but then how do you know that that's correct Now you kind of get this whole chicken and egg thing going on logic and test I mean the problem is is that if you've written enough unit tests there always comes a point where you're going to have to write some set of logic at some point I know it's terrible but you just have to uh oh uh oh oh we're good I know then I've literally written a test for a test once it that's how I knew I've hit in the end the end game is when you write a test for your test you literally test driven development to your framework for test driven development to your software I did this once okay I was a tdd guy at one point and so we'll end up spending lots of more time figuring out and fixing bugs from there too the state of devops Reports say that teams that score well on stability and throughput spend 44 percent more of their time on new features stability and throughput notice that none of that technically supported tdd or did not support TDP right that's just simply saying stability and almost always when it comes to devops stability is like platform uptime or reliability of integration slash end-to-end tests but don't directly measure test driven development though what they do measure continuous integration and continuous delivery and software quality they said I'm going to give one hard take at the end of this about ET integration tests least a correlation between good scores and continuous integration and continuous delivery and test driven development so while it may seem slower actually the teams that practice tdd are usually a lot faster at least in my experience and that at least correlates with the more scientific research from the state of devops reports next pushback test stream development doesn't work I'm sorry but that's a just a dumb thing to say it may not work for you but it does work and it's used to build some of the best software systems in the world Tesla practice test run development for cars NASA used test run development for early space Rockets SpaceX practices test stream development for modern space Rockets Siemens Healthcare practice test driven development for medical systems Siemens I worked on a team that built one of the highest performance Financial exchanges in the world and we use tdd every day all day for at least five to five years that I was there and I'm pretty sure that they still do too many years later sorry but saying that this doesn't work is simply an expression of ignorance what I do I do generally agree with that saying something doesn't work is flat out saying oh this won't work because it's no good I mean it's the same people that dog on htmx while they're building their recipe website right it's just like oh really it doesn't it doesn't work for your recipe website okay I I get it you're right how could you ever have that interactivity of a thumbs up yeah well what about offline yeah you're right those classic websites that we all use offline such as YouTube that I use offline all the time or Twitter or twitch I use twitch offline regularly you know all those websites people that claim that it doesn't work are really saying is I don't know how to do this so the answer to that is for them to learn how if they want to drop it once they know how they're crazy but fine that's their choice so that's ad hominem so remember that's ad hominem so Dave that was that was a poor argument I I do expect more from Dave than that um I do agree though that that doesn't work approach almost exclusively comes almost there are times where it just simply doesn't work like a tdd doesn't work that's just actually a good a good statement I don't think it works that great I think ultimately in the end you create a software that's significantly harder to refactor uh but I have reasons why I think it doesn't work just saying something doesn't work true agree your same team as you that's not a good argument almost always born saying that it doesn't work it's just plain wrong if you'd like to try test room development for yourself I have an introductory free tutorial that you can try there's a link in the description to this video and in the comments so I do check those out next on the pushbacks test driven development can't work for infrastructure embedded systems games Legacy systems my complicated code and so on well yes it can once again what this sounds like to my ears is I don't know how to do it which is fine so learn how but it can and does work in all of these cases and this little little ticker right here that keeps on saying the same four things over and over again driving me uh crazy many many more the fundamental ideas of test driven developments are actually pretty simple and completely generic it may be more difficult for some kinds of code and for some technologies than others but it works everywhere if you're taking see one of the problems with like doing this like you know exactly what he's saying some of the problems that he's suggesting is that you can do it everywhere and you should do it everywhere but you end up building a bunch of just like off off-band logic which is always just terrible like embedded systems you're going to have to mock out the embedded nature of things you're gonna have to write programs in such a way that you can mock things out and see is it necessarily the most fun language to just write a bunch of mocks for in unit test for as it is let alone let alone being able to do it for all of hardware and be able to create these synthesized tests because in the end Hardware versus your synthetic tests don't always line up one for one that means you have to actually replicate an environment that is almost one for one or perfectly one for one would be the ideal goal let's say your embedded project which could be extremely hard to do extremely hard to do and so I I just don't necessarily buy that as a thing one should do technology or language doesn't support unit testing it might be worth looking harder because it probably does if you if you search around enough but if really not then writing a version of X units will allow you to do it is really pretty easy I've done it several times myself in the past I've worked with test driven development with teams building f fpga based systems games and infrastructure as code fundamentally you need to be able to decide what you'd like your software to do and write that down in code that's your test one of the good things and maybe more challenging things for people new to test driven development is that it forces us to pause and consider a bit more carefully what we'd really like our code to do before we actually write the code it's a very common mistake for developers to say things like how can I know what to test before I've got the written the code but you're not testing how the code does things you're testing what the code is meant to do and if you don't know what you want it to do then you probably aren't ready to write that code yet anyway writing a test that's so how do you become ready then like real talk when at what point do you become ready let's just say you have a data source you don't really know plus you have an output you want to produce like say a CSV from this data source at some point how do you know you're ready to start writing code like at some point somewhere you might have to write code just to figure out what is actually the things that are happening so would that be test driven development or is that Spike driven development at that point it says clearly in in the form of an executable specification what we want our code to do is a big part of the value of the whole approach and is the reason why many test driven developers talk about tdd being more about designing less about testing if you can't express that goal for your code clearly I really don't think that you understand the problem you're working on yet or I agree with that uh and I think most problems you don't understand thoroughly anyways to begin with in fact most problems I find that you even think you understand them and when you fully understand it and you do end up writing all these tests out and you get everything perfectly running and you have the most glorious unit test system ever you realize you've already been fundamentally wrong long beforehand and now you have to throw away everything because you're actually incorrect from the get-go and you just simply didn't know because there's no way for you to know until you got to a certain point within the software development cycle this has happened more than once to me just because things change have you ever picked the wrong system because that was the system that was most likely to be the right one like one time I was doing a real-time monitoring of uh of of stats and and then I also wanted stats from like a cold storage version and guess what both of those became deprecated in a completely different Source came up with completely different looks and completely different features and completely different everything which made me have to rewrite the entire pipeline right like there's no way I could have predicted that and so it means every single test I wrote I had to throw away you know how painful that is it's really painful when you have hundreds of tests that you have to completely throw away because ultimately in the end you built it for a moving Target and the moving Target moved it's like Sisyphus you're just pushing stuff up up a hill at least don't have a very clear view of where your design is heading and writing the test before you write the real code is a great way to explore both of these ideas so whatever you do next write a test or not you're not going to do as good a job of the code if you don't have this perspective and tdd forces you to think more carefully from that perspective this is also one of the stumbling blocks though because testosterone development does force you to do these and some programmers aren't used to thinking quite so clearly about what they'd like the code to do this is the real challenge of tdd I think it brings design front and center into the pro the process of software development and it highlights the shortcomings of design more quickly and more clearly than anything else that I know of so me personally I've never really had much of a Clarity in design of code at the unit test level you know what I mean I almost always have Clarity at the end to end level right when you create an interface for say part of your data fetching and all this and then you create an interface for part of your data munging and all that and then you create part of your interface for interacting with the CLI arguments and all that and then you put everything together and you realize oh I really didn't like how I shifted this thing here oh I really didn't like this it almost always comes from the integration points that I realized where my problems were and some things that were a little bit harder like right you could write the world's greatest way to produce widgets but if the widgets and how they're produced is really poor for how you get your data it doesn't matter how great this part is you now have to abstract it or do something to it that makes it really really hard I'm still going to give my whole opinion at the end about integration uh end to end and unit tests this is a challenge is a difficult skill to learn and to be good at I'm not saying here that you can't do good design without test driven development if you're skilled enough then you can but what test driven development does is to help people whatever their level of skill are design to more clearly see the consequences of their design choices it gives them fast feedback on design so that they can learn faster this is a very good thing indeed and it helps you to get better at designs more quickly and more easily this also means that as someone recently said in a Twitter conversation I can explain to you how and why I make the design choices that I make because I'm Guided by test driven development can you do that without testual development yes tdd provides design guide rails that are otherwise it's actually the exact same reason why tdd allows you you're able to take software see how it should be built and then from seeing how it should be built you built an interface in your head and then you wrote it down in tdd and just did it first maybe you put it in a document first maybe you made some sequence diagrams first hell maybe even once with some uml class diagrams hated your life a little bit but nonetheless you brewed that black coffee in the morning got pumped up made some class diagrams maybe some abstract classes you shut your mouth that you mail boy [Laughter] I was missing completely other than through experience or expertise and that is generic if testing development seems like a poor fit it's telling you something about the design of your system changing the design so that tdd is easier is always a positive step in the quality of the design as far as I've seen so again a very very subjective statement designing your code to always work with tdd makes better code in my experience you know again this is a very very subjective State you can't really again this just mostly proves the classic DX argument which is if it feels better it's better DX right that's it that's what everyone's saying that's what everybody says if it feels better it's better DX why well it feels better it feels better therefore it is better is it it is the pushbacks I know what I do and it works statistically you don't and it doesn't there was a distract uh I actually strongly agree with this guy I strongly agree with that completely you don't know what you're doing and no it doesn't work and that's why I'm also super hesitant to buy your tdd study of how production systems fail it found lots of interesting things but what do you suppose the most common line of code says at the point when a production system fails it's usually a comment saying something like to do must Implement exception handling here so you're telling me there could also be a test that says to do enable this test and fix the bug 92 percent of the catastrophic system failures are the result of incorrect handling of non-fatal Errors explicitly signaled in the software boom rust argument or go argument really when you think about that's a go argument too 74 of failures are deterministic they are guaranteed to manifest with appropriate inputs most of the areas that cause production outages like these are caused by the kinds of mistake really 70 only 74 can be cast are people's programs that like that actually shocks me I think that that last one we should take a pause there and say 26 of known bugs or just crazy ass race conditions is that what I'm hearing what that's the that to me that's to me that's like the bigger one we should be focusing on which is how did you get to that point that you're getting highs and bugs 26 of the time thanks that we all make code mistakes that will be caught and so eliminated entirely by simple testing of some kind classic 58 of code 50 this stage I often get pushed back on yes but you can't test everything there are complex interactions and yes that's true but remember 74 were not complex interactions they were completely deterministic of the 26 remaining less than half of those depending on bugs caused by timing and that was timing only through the inputs so about 12 of mistakes are of this more complex variety so why not fix all of the easy things first and get an 88 reduction in production defense is that like the same percentage rust also claims they're going to solve so just use rust that's what I'm hearing right now just use rust you're probably not good at enough skill issue just use it you'll get better trust me it actually gets better quick maths people worrying too much about anything complicated age cases actually it's been my experience that once you do adopt test driven development and its mindset then this final 12 of bugs is more tractable too because test your own development encourages very strongly to design more deterministic systems because systems like these are easier to test can we disable the test just for this release I should when I hear this kind of thing not just because I advocate test driven development because it seems to me also that to express a deep misunderstanding not only of about testing but also what software development in general is really all about yeah you don't disable a test like everybody knows that you don't disable a test you delete a test right that truest way delete the test it goes green you've done it release away release away like we all know that that's exactly how you do it that's always been the way if you have people saying this you have pretty big problems that go Way Beyond testing professional software development is creating things for people with software I actually agree with you it's not about checking off jira tickets or hitting velocity targets or whatever those are just steps mechanisms that are meant to help and dental ways I would argue jira is almost exclusively in that negative besides for the fact of just keeping track of what needs to be done the rest of it was a mistake it seems to me that anyone saying this has lost sight of what it is that we are really doing for a living this is rather like the airline pilot saying I know we're overdue but my shift is over now so let's just land here and take our chances even if we aren't at the destination yet let's just ignore the bad weather in the mountains okay so not all software kills people if it goes wrong but it's still the same kind of thinking our job is to make software that does something useful no no one is is pure psychosis okay it's just here psychosis all right you can't you can't say those are even remotely the same useful the job of tests is to help us to see that our software is doing something useful these are not arbitrary process steps or barriers raised by management this is an essential part of our job as professionals to know that our code works is safe and is useful if we can't do that what is it that we're doing it's not someone else's job regular programming is what we're doing you know what that's the thing is that okay now I'm I'm reserving the Judgment I'm reserving the judgment to the end okay reserving the judgment to the end to do that for us this is always part of the responsibility of any software developer or development if your organization is structured differently to that then your organization's wrong but it's still your job so now the only question is what form should this very occupation of the correctness safety and utility of our code take but even before we get to that let's think about the role of testing in the abstract what is a test of any kind really for I think that the common misconception is that tests prove correctness this is clear ly wrong if I'm a doctor and I score 100 in my final exam does that mean that I can't the very next day make a mistake that kill somebody or maybe even a mistake based on my own ignorance of something that wasn't tested of course not mistakes can always happen we can never test everything more tests of the doctor may increase our confidence in them that this person didn't just earlier he said no you could test everything I thought they're just like yo embedded or games or this or that are really really hard and he's just like nope false easy you could definitely do it but then he just said no you can't actually test everything I mean he's less like to make faithful mistakes than say a random computer programmer doing brain surgery but testing is always only a process of sampling more tests more samples offer a statistically better chance of success but only that never ever proof if you score 20 then you don't get to be a doctor however many tests you have you can't prove success but if you have a single test failure you know that there's a problem and your code isn't good enough unlike doctors code's more predictable and tests are more predictable of those kinds so we can use these failures more accurately 90 pass rate here if one test fails oh it's been the safest course of action is disqualification don't release it I literally can't hear people when the same animation plays twice like at this current point I cannot hear a single word he's saying because I see the same animation twice and I don't know if I'm the only person like that but my brain starts predicting it and being like question mark in three two one question mark change dang it I thought the question mark was there anything else oh there's the question mark see I knew it was coming at any moment my beautiful mom's calling me we can't take a phone call from Mama Mama Jen boss crossing our fingers for luck and simply guessing look at that see I can just feel it I can feel it coming now the next one though is going to contain the air are you ready a test failure is a definitive statement that our code is not working if you release now what you are saying is I don't care that my code's broken you may guess that this particular failure doesn't matter very much you may even be right in your guess but it's still just a guess you don't know tests are directly useful when they're failing they're only directly useful when they're failing so discarding the results when they fail is dismissing them when they are doing the job that they were designed to do so now the only question is how best to test an automated tests are more repeatable more reliable and faster test stream development builds the creation of tests like these into the development process so you get them as a side effect of how you organize your work to achieve other useful things notably the feedback on design that we talked about earlier so this is a much more effective way to create does that mean hair school is untestable you can only write a white paper right is that how you test Haskell is you write a white paper is that what you do I I don't know how it works these tests with less work than trying to add something else like to run and you get better there are more objections than these but these are all common enough that you will probably face them at some points when trying to introduce test driven development to your team or your organization I hope that some of my answers may help you in one second thank you very much I appreciate it is consider supporting our work by joining our patreon community there's links to that in the description below very very nice oh that was loud okay so my opinion on this one it's actually quite simple which is that the more unit tests you have I do think that it's fundamentally harder to refactor I know there's a lot of talk about this but the problem is there's an assumption in most unit tests which is that the interface at which you're unit testing will remain the same in some sense you're doing more of an integration test at that point if your interface can vastly change underneath the hood and nothing about it is actually changing you're more on the integration side than you are on the simple unit testing side which I think is the most interesting part so are you doing peer unit testing are you going too granular or not granular enough and so I always find that the larger you can make a test the better it is and so for refactoring uh whereas on the other hand as far as implementation goes when there is a particularly hard thing something that you cannot get correct on your first try something that is very very difficult let's just say you have a large megabyte array and you have to manipulate memory throughout this array you want something that kind of really gives you the confidence that your minute manipulating doing the bit shifting and all that correctly within this large memory region right that seems reasonable to me that's a great place to get all the way down to the function level such that when you refactor you have to rethink about your test because you are re-changing how you're manipulating this memory and so to me that's like a sign that your test must be deleted and you must rethink it whereas anything beyond that I always go to the other side which is you pretty much need to test something in the larger in the larger sense in the more complete picture I have very little I don't have almost any Middle Ground testing I never like to test large interfaces that do a bunch of stuff because often once you do that you have to start mocking Indian tests you have to start providing these providers you have to start overriding globals you have to start overriding more and more of your program running to the point where are you even running your program or are you just running your mocks are you testing your mocks or your program at that point and that's where my big problem starts happening and so it's like if I get to that point I always find like that's the worst spot to be in either I want to like just simply mock one part the data fetching and all data that's coming back has already been pre-played data that I already know and then everything else is just doing the entire pipeline of the program and then I just you know ensure that like I write out to a file and that's for like my you know for my CLI tools I write out the actions to a file saying this is what I do and I I expect that to happen or else it's unit test for something really really small I just rare rarely write medium-sized tests right integration level tests is usually what I hear people call them and uh or functional tests some people call them functional and it just seems it just seems crazy to try to say that test driven development when do you start applying it to what level do you start doing it at uh because the smaller you make it the harder it is to refactor the more you have to disparate like you have to remove your test completely and redo them because you just by the very nature you have to you just you have to and so the larger the test the easier the refactor that means I have more freedom to play Within the interface itself uh you know just personal big fan of that that's kind of where I always do everything at is that I tend to just put it to a certain level and that's as Max as I'll ever test I don't know I just really uh Dave Farley's 100 yeah see I I I'm not like I think pair program is a great is a great thing to use to like learn something I'm all in onto pair programming perfectly fine with that but I really don't want to program with somebody that long right it's meant to show you how to get started for me not like oh thing you do all the time uh I'm just not into it I just don't think tdd is useful that's just that I think that if you're doing tdd at all points um I think that you're wasting a lot of time I think that it's better like especially if you're doing CLI tools or however you do your tools right or however whatever you build right uh I build uh I build CLI tools so the the things that I really focus on right away in a project is how am I doing my standard in how am I making this more Unix philosophy and how am I going to do integration level testing for me that is the most important thing possible about tester driven debugging exactly I do like test driven debugging I think that that's good like if there's a bug that's particularly hard I think I think that that's pretty good I think that that is uh I think that that is a perfect way to go through it I I'm just fine with that and if you want to keep that test you can go for it and keep it if you feel like it's going to get refactored out right away sometimes I find that when I do that I both delete the test and the code and refactor it into something slightly different right I find that it can be a you know it's a little different and someone asked where can you go if you want to submit anything for me to react to go to the Reddit r slash the primagen react and I go through that 100 test covers 100 test coverage is both a pipe dream and a wet and a wet dream of uh whiteboard masturbation it's not real it's never been real always super super simple to show you this which is let's go like this uh you know R you have an array that's a number and you have an index you know like how about this one up two and a number right and I like this let out equal zero uh four let I equal zero I has to be less than uh up two uh L plus equals a I return out uh r there you go I just I I literally look at this 100 test coverage right 100 uh 100 test coverage and everything is good nothing about this is a mistake 100 there is no bugs in this code yes there is there's very much so bugs in this code right like this is very very simple and this is the problem with doing this type of stuff is that it's 100 doesn't mean anything and if you're looking at this and you're like well I'd never write code like this you're right you wouldn't write code like this but the reality is is you write code some other way in which goes through and has the same problems but you're just trying to like just trying to pedantically Define that 100 good despite the fact that I could just easily destroy it the fact that I could come up with that in virtually no it almost

Channel: ThePrimeTime

Views: 143,926

Keywords: programming, computer, software, software engineer, software engineering, program, development, developing, developer, developers, web design, web developer, web development, programmer humor, humor, memes, software memes, engineer, engineering, Regex, regexs, regexes, netflix, vscode, vscode engineer, vscode plugins, Lenovo, customer service

Id: 0IhsNvUZS3s

Length: 46min 51sec (2811 seconds)

Published: Mon Jul 31 2023