Everyone Is WRONG About Testing And What YOU Are Going To Do About It

everyone on the internet that talks about testing is just wrong and if you're a software developer looking for information about how to write test the best ways to write test the different things you need to be thinking about when you're testing you've observed this already you have all of these brilliant software Engineers that are offering up you advice with the best way that you can write tests and the only ways to write those tests but here's the problem we have experts that are telling us that we need to write unit testable code and that means we should be having interfaces for things so that we can mock things out but we also have people telling us that mocks are the enemy mocks don't represent real code we should never be using mocks and of course we have people saying that we shouldn't be writing unit tests at all unit tests are not going to be representing the actual systems working together we need system level tests integration tests unit tests don't offer us any value they're not realistic to do and even though unit tests are supposed to be testing units of classes which are going to be individual methods they're not supposed to be brittle either so you can't have actual unit tests that are coupled to implementation details but because we're not going to write the unit tests anyway and because we're writing these system and integration level tests they're not only going to give us the best coverage but they're just the best thing to do because they're the easiest to maintain as well you see the problem with this you have all of these different opinions and all of these experts telling you things that just don't line up I've even seen people say that test coverage is just false confidence and I mean I agree that's the only thing you're looking at but so what are we expected to do well I wanted to make this video to talk about this but I also wanted to share with you that I don't think it's specific to software engineering and testing at all now this took me a long time to learn but the example that I wanted to walk you through is actually about going to the gym now many of you might not know this but I am on the side a hobby bodybuilder it's something that I'm very passionate about but many years ago when I was trying to figure out how to build up my leg and bodybuilding I was trying to learn about squatting and the exact same thing happens when we go to look at information about squatting you have people that tell you the bar needs to go up high on your back and you need to stay upright you'll have other people saying to put that bar Lower on your back you need to have your legs wide you need to have your legs narrow and sit right between your knees oh and your knees yeah they need to be tracking your feet but they're not allowed to go past your toes and the only way to squat properly is to go to parallel or below but also if you go to parallel or below you're risking damaging your knees so how the heck can anyone possibly go well now I know how to squat and I'm just going to go do that from Reading information online or watching videos but the parallel here is that when we take something like a squat and if you aren't someone that goes to the gym honestly go try this out right now open up a new tab go search it on biger Google and search how to squat you'll see a million different variations about what's right the parallel though is that something like the squat and the instructions we get are just different tools for how to apply the squat it's not one of these ways being objectively right or objectively wrong there's variations to all of these things that have pros and cons and different reasons why you do them so for example a lot of the time when people are sharing information about where to put the bar on your back they're not taking into account your limb lengths it might not make a lot of sense for someone to position the bar a certain way or to be upright or leaned over and if you're not factoring in the limb lengths when you're trying to look at this stuff it's going to be really hard to apply that properly so these are tools that are based on context and scenarios and the exact same thing is true for our tests the point of writing tests for software development is so that we can have confidence as we're delivering changes that's the point of them it's not because you get a high score somewhere and I mean maybe you do it the place you work I don't know but I have never seen it be the case where we're strictly just writing tests because we got to write tests the point of writing tests is so that we have confidence in the changes we're making and that can look very different depending on what you're building how you're building it the stage of the product that you're building and also the team that you're working with there are so many other variables that you're going to want to factor in when you're thinking about what types of tests to write so anyone that's telling you as a blanket statement this is the best test to write this is the best way to write tests this is the best way to structure your code to do it and they're not talking about the different context it's just not fair it's not accurate to be able to have blanket statements that say the best way to do things without offering up context as to why so in this video I'm not going to go into all the different details and nuances of the different types of tests and things like that especially because people are just going to start debating the terminology and language and miss the point that I'm trying to make here which is that there isn't one type of test that you want to write you're probably going to want to write different types of tests a combination of them and as the product you're working on or the project changes to something else your opinions might change about how you go write those things and I'll share my own experience because I've definitely Chang my mind about the tests I write based on different products and this first example is for all of the people that say unit tests are not supposed to be brittle you can't just write unit tests I have absolutely worked on a very success uccessful product in a small engineering team that was basically all unit tests we had almost no other types of tests until very late in development we could iterate super fast we could find bugs before the tech support could even tell us that they were existing because we had Telemetry wired up it just worked really well for us and yes someone's watching this going well it's not because you wrote unit tests and that enabled you to be better you just got lucky that you happen to write unit tests and everything else got you to that position and sure you can say whatever you want but I've been able to work on a successful product doing this and if I could go call up the other Engineers that worked on this with me they would tell you this worked well for us we were happy to develop this way in a total opposite direction the recent project that I've been working on called meal coach has required that I write functional tests and almost no unit test to get the type of confidence that I want and I've already made videos on this explaining the evolution of how the testings looked because for me writing unit tests across everything like I did in this other product that I was talking about just did not make sense I needed something at a functional level and in fact I even wrote those tests when I didn't have the infrastructure set up the way I wanted at all but it worked really well for me initially and when it started to not work well I pivoted I adjusted I changed those tests to use the new infrastructure that I had in place and it worked awesome and it's not like I ignored the unit tests either I had situations along the way where because I wrote my code to be unit testable I was actually able to go write those unit tests very easily in the areas that needed it all right so to summarize my message in this video it's that yes everyone is going to have different opinions about the best ways to do things and unfortunately it's your job to figure out what parts of what they're saying can be applicable to the scenarios that you're working in you need to remain pragmatic in everything you're doing and that's going to mean understanding the pros and the cons of the decisions that you need to make so if someone's telling you that unit tests have all of these pros and someone else is telling you unit tests have all of these cons try to look at the list try to compare them try to understand why those pros and cons exist apply that to what you're working on the same thing for other types of tests like integration tests or system level tests end to end tests all of these things have pros and cons you can then take this same concept and apply it to all these design principles and software architectures as well so someone's saying to me that writing unit tests and having interfaces is is just Overkill and it's tons of extra work I mean it takes me literally half a second to rightclick and extract interface on something I don't mind the extra work for it it works for me I'm happy to do it in other situations that may not apply and I may change my mind but it's important for you to be able to take the information digest it understand the pros and cons and then make decisions based on your own experiences and do keep in mind that those experiences you have will change so just because something looks the same and you might have seen something similar before do try to keep an open mind to understand if the scenario is actually the same always just repeating everything you've done just because it looks the same may not always help you but it might be a great starting point at least so try to keep an open mind so with that said I do encourage you to write tests that might be the only thing we can all agree on is that some amount of testing is going to be helpful to give you confidence and if you are interested in seeing how my testings evolved in one of my recent asp.net applications you can check out this video next thanks and we'll see you next time