Coding Blocks - Clean Code – How to Write Amazing Unit Tests

Episode Date: January 23, 2017

When and why should you write unit tests, and just how important are they? Take a listen and see what YOU think. Podcast News iTunes: AUS Dan G, bryangrove, Criviere, Kasprs, sulhogar, Niil Ohlin (Neil Ilin) Stitcher Reviews: indiegamer21, makeACaseForCamelCase, athyng, brokenrelay, El_Zilcho MongoDb and ElasticSearch Ransomware Attacks http://www.pcworld.com/article/3157417/security/after-mongodb-ransomware-groups-hit-exposed-elasticsearch-clusters.html Alexa 7 Minute Workout https://www.amazon.com/Pargee-7-Minute-Workout/dp/B018WUNBE6 Question: […]

A manager, a mechanical engineer, and a software analyst are driving back from a convention through the mountains. Suddenly, as they crest a hill, the brakes on the car go out, and they fly careening down the mountain. After scraping against numerous guardrails, they come to a stop in a ditch. Everyone gets out of the car to assess the damage. The manager says, let's form a group to collaborate ideas on how we can solve this issue. The mechanical engineer suggests we should disassemble the car and analyze each part for failure. And the software analyst

says, let's push it back up the hill and see if it does it again. Sounds about right. Of course, the manager wants to have a meeting, right? Right, right. Oh, man, I'm terrible at telling jokes. My delivery sucks. I'm definitely not telling jokes. My delivery sucks. I'm definitely not Ron White.

All right. So here we go. You're listening to Coding Blocks, episode 54. Subscribe to us and leave us a review on iTunes, Stitcher, and more using your favorite podcast app. Visit us at CodingBlocks.net where you can find shoutouts, examples, discussion, and more. Send your feedback, questions, and rants to comments at CodingBlocks.net. We can find show notes, examples, discussion, and more. Send your feedback, questions, and rants to comments at CodingBlocks.net. Follow us on Twitter at CodingBlocks or head to www.CodingBlocks.net and find all our social links there at the top of the page.

With that, welcome. I'm Alan Underwood. I'm Joe Zak. And I'm Michael Outlaw. Alright, and now it's time to get into the fun part of this, which is reading the names from our reviews. So we got quite a few in between this episode and last. So thank you very much for taking the time to do it. Super, super appreciate it.

So here we go with iTunes. We have from Australia, Dan G, Brian Grove, Crivier, Caspers, Sulhoger, and Neil.

To give you a little pronunciation guide there. Neil Illen. He did. He gave it to me, and I wanted to make sure I didn't mess it up. All right. And with Stitcher, IndieGamer21,

MakeACase4CamelCase, A Thing, BrokenRelay, and ElZilcho. Again, seriously, thank you for the reviews. They, as always, put smiles on our faces, so thank you for that. For the full show notes on this particular episode, if you're driving, when you get back, you can click the link. It is codingblocks.net slash episode 54.

And we wanted to get started with a little bit of news. Something that came out, it might have been this past week, I believe it was, is people were getting ransomware for their MongoDB and Elasticsearch installs. And you know what's stuck about this is? It could have been totally avoided. Like basically, it was people that had installed it and left the default passwords and usernames and all that stuff in place. So you might want to check and make sure that you've got your things locked down. But be aware, like, if you're doing any kind of, you know, production site right now, these two were called out. But there's a potential for tons

of software out there that comes with their default credentials being like that. You want to make sure you go and unlock that stuff down. The whole ransomware thing in general, though, has just gotten scary. Oh, I don't like it. The fact that that's even a thing. Agreed. It bothers

me greatly. The Bitcoin ATM guys are loving it though right yeah it's quite a business in some major cities these days and a lot of people will get the ransomware and they don't know how to buy bitcoins and so i've heard about people like um you know they call their friends in like new york city or somewhere where it's a little bit easier to just kind of meet up and get this stuff in order to get the bitcoins they need to pay the ransom man it's bad you definitely want to keep backups of your personal things and man i don't know it's just kind of scary uh one thing because we're we're developers and one of our slack channels is actually fitness and health

it there are a lot of us that try and figure out a way to sort of maintain that because you know we sit at a keyboard most of the day so i got in uh an amazon echo for christmas and mostly i like it uh mostly so i got the echo dot let me take that back i got the smaller one so the speaker's just not quite as good i've heard the bigger ones and they sound amazing the little one you know if you crank it up much past six or seven it gets a little tinny but there was something really cool one of the skills that you can do is a seven minute workout which is really cool you basically say start it and it will like in intervals tell you okay pause are you ready for your next one you say yes and it'll pick up okay so just rewind one moment for those not familiar with

alexa and particularly when he said skills uh skills are something that you could add to the alexa device made by amazon to give it new functionality yep and it's pretty nifty it's so you as a developer can go out there and actually write a new skill for the Amazon echo products, which is really cool, right? Like this one, the seven minute workout, it was a great idea. Hey, start Alexa, start seven minute workout. And then she'll basically be like, okay, let's, let's do this. And she'll tell you the exercise you need to perform. And if you don't know how to do the exercise, like there was one that was planks, right? And, and my wife was like, what the heck is that?

And you can say help and it'll tell you, okay, you know, lay across something flat, stretch out, whatever. So it's pretty cool. It's nifty, but it's a really good way that if you're sitting there and you have that thing sort of in your room, you can say, you know what? I need to do my little workout and it'll take you seven minutes. So really cool, nifty thing. So you should check it it out we'll have a link in the show notes for it and uh one other thing that came up on slack today that i thought was a great conversation so we all know programmers that literally joe is one of them that programs day and night like there's no off switch word like i even said him one day, I was like, where do you get

the energy and the time to crank out as much code as you do? I do it in my day job. Yeah, no kids. It's a big deal. And this came up in Slack. Some people were like, wait, do you have to be one of these people that is coding all the time to be considered a great programmer? And I think that's a misconception. one of these people that is coding all the time to be considered like a great programmer and and i think that's a misconception like when i program at night it's almost always i never complete a single thing right like i mean and i hate to be that way but but my nighttime programming or my off work time programming is usually exploratory it's playing with frameworks or checking out new methodologies

or reading up on how to do things in different ways. It's never really as much about creating a finished product as it is about, hey, let me dabble in some things that I want to do without having to go from A to Z on it. So I don't know. Well, I kind of view it as there's two different forms of night programming though.

There's the kind where you're just committed to whatever it is you're doing at work, and you just want to keep going or whatever. And then there's the learning exercises like what you're describing. Yeah. So, I mean, either way, hopefully you're doing it for the learning or just the practicing of it. Or maybe you want to try new techniques or frameworks. But, yeah, sometimes we do it for work. I will say there were two interesting things that came out of it. Hopefully, you fall in the middle of this category

if you're one of the people listening to this and this resonates with you. There's the people like me, if I actually do have a serious project that I want to do, I overanalyze it to death. I'm like, I'm going to use this particular methodology. I'm going to make it this framework. I'm going to put these libraries in it. And I've architected out this beautiful thing. And by the time I'm done doing that, I'm like, man, that'll be awesome if it ever gets done. And then there's the other people that just start doing it.

And if you just jump in and start doing it, then the thing is, you're going to get more traction, you're going to learn more things, you're going to do more. But it's like you get stuck in trying to research, well, should I use Flux or should I

use Redux? And really, all you want to do is try some React code and neither one are probably going to matter for what you're actually trying to do. But you got to know what the best way is, right? And so it's that rabbit hole. And there's somewhere in between, right? Using your practical knowledge, the experience you've gained over time and putting it to use quickly, right? Like that whole MVP, the experience you've gained over time and putting it to use quickly, right? Like that whole MVP, we talk about it all the time that if you can get that minimal viable product out there, you're doing better than 99% of people out there. So, you know. Yeah, no doubt. And I will say, I do think there's a definite advantage to doing a

lot of coding on a side and reading a lot of articles and stuff that, you know, there's no doubt that it brings insight and peripheral knowledge. That's, that's useful, but it's absolutely not a requirement. Uh, I know a lot of great programmers that do a nine to five and they're done and that's fine. And that's what they want to do. And, and, you know, there's no problem with that. No one can give you a hard time about that. It's a normal existence. Um, and you know, if you want to do extra, then great. But I do, when I do take the time to, I feel like this should be one of those

most interesting man in the world commercials. When I do take the time to code in my free time, I like to make sure that my small project can scale to a billion concurrent users. I'm horrible about that. Dude, that's actually where I waste 90% of my time.

It's like, wait a second. Do I do a Docker swarm? Do I do Kubernetes? Wait a second. Do I do VMs? I need another server in my house so that I can replicate 20 VMs, right? This is why I never get anything done.

Not on a personal project. It, and then cutting turns into shopping. It really does. I swear to God. Well, here's this project that I know I'm never going to finish, but it's going to cost me $1,000 because I need that new hardware right there. It's funny that shopping can be easier than getting something done. There's so many times when I start out, even house projects, like I start to do a housing project around the project around the house and I'm like, well,

if I just had this hammer next thing, I've spent, you know, an hour and 20 bucks on Amazon and I haven't actually done the project and I'll probably never will. And I think it's the same thing. You got a sweet hammer. Yeah. The shopping kind of gives you a way to kind of give yourself a little pat on the back. Like you did something productive, but it doesn't really count. You know, that's so true. It's a dangerous thing. Like really just getting down and starting on something

is probably the best thing you can do. So, you know, hopefully you fall somewhere in between there. You take your past experiences, but then you just start putting rubber to the road. And then when your spouse wants to know why you're spending all that money, you got to explain to her, well, listen, I'm trying to learn Angular 2. It's a deal. It's a big deal. So it's important. And I'm saving us money because if I went to a boot camp,

it cost me three grand. I'd have to pay for airfare and room. That gets expensive. That's awesome. So how about we'd like to give you some stickers. So if you could send us a self-addressed stamped envelope,

you can find the address at www.codingblocks.net slash swag and send us a self-addressed stamped envelope, and we will send you back some amazing stickers. Yes, and for a definition of what that is, you can go to episode 53 because we described what a self-addressed stamped envelope was there. Well, if we repeated that in this episode, it wouldn't be very clean

code of us to repeat that description. Are you sure? And we do have a winner for episode 52's version of, or not version, the contest for clean code. And that was Kevin Kimier. Kimier?

I'm not real sure. Kimler? Kimier, no. I don't know. We have it spelled both ways on the same line. We'll reach out to you, though. So if you get an email from us then uh you will one or both of you kemler i think i typed i don't know what happened there anyways yes you will be getting

your copy of clean code so just respond to us and it will be in route and that wasn't awkward not at all all right and i got a bunch of stuff I want to mention, though. I'll try to go fast here. So we got some postcards from Roadclaw and Gdansk, Poland, which is fantastic. So I don't know what it is with the Poland people, but they sent us postcards, and it's fantastic. And the rest of you guys have the bar set for you now. So setting bars. Community Spotlight just released a series of posts recently highlighting some of the people that we get to hang out with, um, in Slack and Twitter and whatever, just people

kind of friends of the show that are doing really awesome things that make all developers lives easier. So, uh, you could find articles on Zach Braddy, um, James Sedar, the cynical developer and MS dev show on our blog. And, uh And we'll have links to that in the show notes. And so you should go check it out and give them high fives. Finally, we got probably our favorite letter yet, which was a letter from Ben. So thank you, Ben. And he sent us some artwork and just wrote us a really nice letter. And we really appreciate that.

We're probably going to frame it. That's how good it was. And inside that letter, he asked us about advice for a new programmer. And so let's say Outlaw, what's your advice for a new programmer? Keep trying. Keep trying?

Okay. I like that. Alan, what about you? So do we want to mention his age? Yeah. Okay. I mean, now you've put it out there. It'd be odd if you didn't now. Well, he's 12. So I found this really exciting.

And as a 12-year-old, it's about the time I started programming. There's lots of cool stuff you can do with it. Like you're starting to get into algebra. You're starting to get into all these things, right? Like you can write little, little programs to kind of do your math work for you. You can,

you know, find useful things for them. If you're into video games, find, you know, find something that would interest you in your video game, but, but come up with small little projects that you can,

that you can play with. And that will be how you, how you grow to love to the stuff, I think. Yeah, I agree. And my device that I wrote down how you grow to love to the stuff, I think. Yeah, I agree. And the advice that I wrote down here was basically just make something fun and launch it. And Ben, you're already doing it. We saw your GitHub account and saw some of the projects you were doing. And it's so amazing. I know college graduates that can't use Git. And so it's just really impressive. And so it's really inspiring to us to see you doing such

cool things. And so just keep up the good work. Yeah, man. Super exciting. And thanks for listening. Yeah, and keep us in the know what you're doing. We'd love to see it. Love the chart. Yes. And kind of in a similar vein to what we were talking about,

I started a recent series of videos that I'm working on. I'm calling Mini Code Adventures, where I well, I'm calling mini code adventures, um, where I'm basically just trying to focus on short projects that you can do while you're watching Netflix, basically. So I'm looking at things where you can bring in other packages, spend 15 minutes, you know, not even be paying that much attention, just do something kind of neat and fun, um, and exciting. So something you can kind of be proud of, even though it doesn't actually take a lot of effort. So I've got one episode just on using human to make websites and human can be used for all sorts of different other stuff too. So you should watch the video and find out.

But, um, I kind of use that as a bootstrap for the next video, um, which is, um, making a real simple website with markup chains. And I think the video is under 15 minutes. So, um, by the time it's posted, that will be live. And so you should watch it. I think Alan's about to have connection over here oh gosh it's got an e in there but i know that yo install whatever because when i was i watched the entire video which by the way i really enjoyed but every time you said human i was like

i had like that that seven minute abs like Twitch, right? No, no, no. Like Alan forgot to take his medication. Every time I said it, I was like, oh, Joe. Yeoman. I thought you were giving me like the you the man point, though. You the man, yeoman.

I was like, I know, I know. You're the man. Alright, I digress You're the man. All right, I digress. Oh, man. That just got amazing. That's awesome. All right, well, what do you say we dive into tonight's topic? Let's do it.

Tonight, we will be covering clean code unit tests. Is this your favorite chapter in the book? I love the topic of unit tests. Is this your favorite chapter in the book? I love the topic of unit tests. That's definitely true. Well, I should say every time I do unit tests, it makes me feel more confident about the code, so it makes me feel really good. So maybe that's why I like things about unit tests.

It makes sense. I definitely associate good things with unit testing. Every time I see them, I know that the code is probably factored well. I like the kind of documentation you get out of it. And it just shows a level of professionalism

that I like. So whenever I see any sort of project on GitHub or whatever that has it, it's just like a good feeling. Awesome. I'll make sure I include

a folder that says testing on it when I do it. You don't actually need any testing there. If you get one of those little 100% passing GIFs in there, that would be great too. That's right. Oh, you said GIF. Dude. We got to restart this show now. What other quirks can we

step on for Alan tonight? Just don't call it Earl. Please don't call him Earl Oh yeah, you should head to our Earl You can't even say it, right? No, that's hard to say But in case you're wondering what an Earl is www.codingblocks.net

And it'll make Alan so happy Alright, so let's get into the first part of this Was the three laws of TDD. You may not write production code until you have written a failing unit test. You may not write more of a unit test than is sufficient to fail, and compiling is failing. And you may not write more production code than is sufficient to pass the currently failing test. Now, if you will recall, when we did the chapter on comments, I pointed out that in the rules of test-driven development, never once was there one of those rules that says, okay, now's the time where you would write the comment. It doesn't exist.

You really shouldn't have to. Yep. But I think the word law is a bit strong here because a lot of production code bases, you know, good luck even getting a test written. It's so hard to do that in the beginning. I guess you could write the test, but it's just going to take a lot of code

to get that first one passing. If you're doing a true unit test and a true enterprise application, not enterprise enterprise but a true large deployed application well i don't know maybe maybe not like their point was literally this should be almost like a 30 second exercise in the book he was saying you know if you write your failing test and then you immediately go over and write the code to start making that thing pass, you really haven't spent that much time, right? So this is obviously new methods. To your point, if you're working in an existing system and trying to, you know, that's a little bit of a different beast, but. I actually, so from my own experience, I kind of feel that if I'm working on something that is completely greenfield, like I

don't even yet, I haven't even decided what I want this thing to look like yet. I find it much harder to start with a test in that scenario. But if it's already a framework that's brownfield, there's already some structure about it, and I'm just adding a new class that needs to adhere to something or kind of fit within that puzzle already, then I kind of already have an idea about what I might want the unit test to look like or what i want to test and what i wanted to what i want the ultimate thing to do yeah we don't know i don't know about you yeah we talked about writing learning tests which is great for third-party integration or things that are real process heavy but a lot of times what i'm doing that sort of exploratory stuff it's a mix of like server side code and like client side and that's the kind of stuff that's really hard to test especially when it's just changing every minute. So yeah, that's tough to do.

I wasn't even referring to exploratory tests though, but yeah. Yeah. So the next section that we had in here was keeping your tests clean. And, and the author pointed out that one of the problems is as you try and do this, is your unit test code could quickly grow, right? I forget they had some sort of metric in there. They're like, if you're writing X number of tests a day, then that's so many hundreds a week and so many thousand a month, right? And that can grow into a beast and that can become unmanageable but then there's we'll get into some of the flip sides and it brought up the question is dirty test

code better than no test code so if if you're in there and you need a unit test you just write something real nasty to get it to get it in there is that better than not having it at all yep i totally really think it is yeah because a lot of you don't i think a lot of people assume that testing is easy and they just don't have time right now but once you start to write those tests and you end up writing the bad toast test i think you realize just how untestable your code is so i think it's easy to make assumptions about the quality of what you're working uh working on that are harder to make if you've got tests that show you just how crappy it is well now that's different though because you're talking about you're kind of implying that you're going to refactor though right you're you're whereas what the way i interpreted the question

is let's say i stumble upon some code some code that somebody else left in the repository, right? And there's some test code there, but the test is just awful. Can't read it, right? It's not very readable. It has a lot of dependencies baked into it or a lot of assumptions baked into it or something like that. There's no real explanation in it. Maybe there's asserts on a half dozen things. You're like, wait wait which one of these things

do you really trying to test like that's the type of unit that's the type of dirty test i'm thinking of not i'd take that over no test because just that being testable at all or having testing even being a thought is nice i don't know man and he gets into it here in a minute and actually let's let's step into the next point so here here's the problem. If you have really dirty, unreadable tests that would not be quote-unquote clean, they have to change as the production code changes, right? And so if your production code changes and that test is now failing, what's the likelihood of somebody going back and maintaining that

at that point, right? Like if it was impossible to read in the first place, what are they going to do now? They're going to delete that test. Right. Or I would. Yeah, totally. If it's,

if it's a horribly written test, then I don't see the point of having it. But obviously Joe disagrees. Yeah. I mean, if you aren't writing tests, then there's like a 90%, 95% chance that your code is untestable.

And so just by having some tests there, I think it kind of encourages some good behavior. And so over time, I think those, those tests, if you keep writing the bad ones, will eventually err towards good. And it's easier to refactor the test than it is to start from scratch. Well, yeah, I'd rather delete the test and then write something that means something that makes sense. Or maybe that test doesn't even, you know, maybe it's not even meaningful. Maybe that's why it's so hard to read so difficult is that it's doing too much. And maybe there's other tests that are already doing those things better.

Yeah, I sort of and I mean, the author definitely has his slant towards this but i i feel like especially in the case of a test if it's not readable then there's a big problem because the whole purpose of a test first is is like we've said it's to give you confidence in what's going on but if something fails and you go in there and you can't figure it out like you've got a big problem. How are you supposed to know how to validate what's supposed to be happening if you can't even figure out the logic that's there? You shouldn't be spending that much time in your tests. I mean, I do understand where Joe's coming from, though, which would be, at least if there are unit tests there, then the chances of you having baked-in dependencies that make your code harder to test, because you already have some unit tests, even if it's a bad one, then you

probably don't have baked-in dependencies. Right. Yeah, so would you rather not know why something's failing or not know that it's failing? Man, that's a... Yeah, but it could be failing and that might not be a meaningful test. I've seen that too. That's true.

I mean, he even says the dirtier the test, the harder they are to change. And as the coding goes on and the code base grows, the test can become a liability due to their dirtiness, like the technical debt that you'll pile up. So you already have some technical debt with your main production code

or most places will. And now you're going to also pile on technical debt with your unit tests. And that seems like that's really difficult. And most developers would end up complaining about it. He even says it, right? Like most teams would end up complaining about the fact that even says it, right? Like most teams would end up complaining about the fact that they're spending so much time trying to make the tests work

that they end up scrapping them, right? Yeah, which can then lead to a whole slew of problems. It does, right? If you don't have any tests. Definitely does. And that's actually the next section we have here, right? So, who's picking this one up?

I'll go with it. Three points they mentioned here. Production code defects rise. So more problems. Fear of changing code increases, which is what we mentioned. You know, you lack the confidence to do things. And cleaning slash repatriating code decreases due to lack of confidence. And I totally agree on all three fronts there yeah there's a great term for this though in regards to like when you don't have

um that test code right then you can it can lead to your production code rotting. Yep. Because of, like you said, sorry, but like you said, the fear of changing the code increases. So because you're afraid to change the code, then over time that code just grows stale and rots and doesn't really become anything meaningful. It's no longer meaningful anymore. Yep. And one of the things that he pointed out that I really liked was he said that your test code is as important as your regular production code. It should be treated as a first class citizen. It should be one of the things that you really want to put effort into to make sure that it runs well, it works well, and it does what it needs to do.

Yeah, I almost wonder if it shouldn't be treated higher, though. Higher than the production code, because without that test code, how do you know that the production code even does what you want? You don't. Right? You hope that it does. You think that it does. You've ran through maybe a couple scenarios or use cases on your

single environment, but you haven't tried it in a production build server environment, you know, where it's running the test cases in its own isolation environment, you know? So, yeah,

I kind of think that it's higher. Nope. And fair argument. It's funny. The next one that, that they had in this particular chapter was they enabled the LTS, which I didn't love the title, but I get where they're going with it.

So basically, it makes your code flexible, maintainable, and reusable. That's huge. Where's the Illity there? Right, and that's kind of what bugged me. They said they do the Illities, but I think there might have been one spot.

Flexibility, reusability, maintainability, fearability. Oh, wait, that wasn't one. Test enable. That's good enough, right? Changeability. But yeah, and they also, this is one thing that I thought was interesting that I'd never really thought about before was they basically enable you to improve your architecture as you move along. Right?

Because if you have tests, it's like he said, you can no longer keep those dependencies baked in because your tests will fail. And so you really start coming away with a cleaner architecture as a result of having these things in place. And I think the whole thing this is really striving to fight against is that situation where you start out on a new project and somebody asks you to add a new button and it takes you five minutes and you do it and it's easy. And then two weeks later, they ask you for another button and it takes a couple hours because you got to look at this and you got to make sure it didn't break that and the build's kind of weird and then next you know it's a couple months down the line and every new button is you know three meetings and two weeks and it

still ends up breaking and so by keeping these things flexible and maintainable and reusable and knowing that you can make changes with confidence it really makes a lot of things easier and all this is just designed to make your life better. So even though it feels like more typing and it is more typing and it is more code, the net result is supposed to be much, much better and much more time savings down the road. Yep. All right. And that's it for that section.

So time for us to beg for reviews because they mean so much to us and they really help us. And I know that it's annoying and we do it all the time anyway. And it's because it's so important to us and because you guys do it and it really helps us and we appreciate it. So please go to codingblocks.net slash reviews and hook us up yo all right so with that it's time for my favorite portion of the show survey says all right so in our

last I got to do it that way it's the only way you can say it you can't do it another way don't look at me like that i saw that all right so our last survey was when pc gaming a console-like game what is your preferred weapon of choice and your choices are number one it's the xbox controller next the playstation controller followed by the steam controller followed up by anything made by a logitech and rounding it out is mouse and keyboard wasdy for life all right so let's go i think maybe alan went first last time. No, you didn't? Okay.

He's shaking his head. He looks kind of confident this time. All right, Alan, what say you, man? What is your choice? What do you think won the survey? Mouse and keyboard won because we're asking PC people what they like to play. But it's a console-like game. It doesn't matter.

And the percentage is what I'm not sure about. I'm going to go with 38%. 38%. All right. And we're playing by Price is Right rules. So 38%. 38. All right, Joe.

Yep. And I'm in the same boat. Just because the keyboard and mouse was an option. Even if we say console games, I think that that's going to win by 70%. 70%? Yeah. That right there, my friends, is confidence. That's how you do it.

You lost. You play big. You lost. You bet big. You live big. That's living large right there. I may lose this, but I'm making a statement. Oh, yeah.

You lost. You lost. Let's not be confused here. Did you just do WASD for life so well? WASD for life. WASD for life. King symbols here. Nerd king symbols.

All right. so it was a mouse and keyboard for the win even though joe very carefully wanted to point out that this was console like games nobody cared it was wasdy for life and it was 51%. Nice. That's pretty high. I mean, considering there's some decent controllers in there, like the Xbox controller, the PlayStation, I mean, those are all good controllers. Yeah, Xbox controller, 30%. That's pretty high.

Yeah. That's pretty high. Yeah, I was really surprised to see that, that it was as popular. I really expected, I wasn't really, I didn't have much expectation for steam or playstation but logitech i did um only i guess i was thinking more about like um uh like flight simulators or any kind of racing simulator i thought that that might

uh rank higher than it did where did they hit at um, Logitech was the next one, but it was only like 10%. Yeah. Keyboard smashed it. So since this topic is on unit test, let's do a survey that's on unit test. So the survey is how much of your code is covered by unit tests? And your choices are what unit tests? Oh, zero. Or those old things.

It's probably like 25% or less. Or number three, we try, but we're somewhere between 25 to 50% depending on the project. Or number four, we're on top of things our tests cover 75 percent of our code next is we're amazing our code is covered by a hundred percent by unit tests and sprinkled with the glittery dust of a unicorn's breath and lastly wait work or personal work. Um, not so much personal.

You'd be proud. All right. So you're so good. So we'll see. You could definitely tell who does the poll. Mine are so vanilla and you're always so good. So,

so we'll see, uh, how, how that one, uh, comes comes back i'm curious to see so let's get back into clean tests what is a clean test and what does that mean to you means it's readable and not only oh sorry it felt it felt more like uh real estate in that regard like you know real estate what's the three most important principles of real estate oh yeah location location location and the three most important uh principles of clean test readability readability readability

yep try to say that 10 times fast and a big part of that is not so much the code in the test although that's also important but also just the name of the test and the way that your test is kind of, um, you know, test class. And however you've got that set up, which I'm sure we're going to talk about later. And one of the things they said about the readability is it might actually be

more important in unit tests than in the production code. And this kind of goes back to what we were talking about a minute ago. And I might agree with that because you have to understand what in the world you're actually testing. And if you can't take a look at that thing and discern that fairly quickly, that's a problem. That's a big problem. Yeah.

I've written some terrible integration tests where it's like, ask them stuff, the cart checkout, um, do some other stuff. And yeah, it's like, there's no,

like, where's the assert like what's the past failure conditions like what is going on here are we just doing random stuff and looking for an error but that's not fair that's a that's an integration test right like you can almost expect some of that that's a different chapter yeah this is unit s uh let's stay on topic is there an integration test chapter no yeah. Yeah, I didn't think so. I just don't want to talk about integration tests because I hate them. But now that you brought it up, we've got to talk about the difference.

Yeah, go ahead. Take it away. So a unit test, in my definition, or in popular definitions, has dependencies on nothing outside of it. And some would take that even to an extreme to say like if you are testing something that requires a clock, for example, that your code is not dependent on the system clock. Or if you're testing file system related things

that you have no dependencies on the actual file system, things like that. An integration test is where you do start introducing those external dependencies, even if it's something as simple as the system clock or access to a file system. The system clock though, come on. Those people are not the life of the party. Who do you want to work with? People talking about system clock and unit tests. Those people getting it done.

I mean, those people sound like they'd be fun to party with. You know why? Because they're going to get the party done right because they already tested it. But, I mean, I know you're saying that, though, but actually that was given as an example in the book where he mentioned um he had something that he wanted it to execute you know like every five seconds and that in a unit test he would actually have the clock would be you know mocked out to where it wasn't he wasn't dependent on the actual system clock so that he could step one you know one quote second do some some stuff, check some stuff, and then step the quote

clock one more time ahead to do some more tests and checks. Depending on what you're doing now, I don't know that I've gone to that extreme with, but I don't know that I've actually had to do anything that was that dependent on the clock cycle.

I would like to see it. Definitely sounds interesting. If a co-worker came up with that and I was in Polaroid, I would like to see it. Definitely sounds interesting. If a co-worker came up with that and that was in Polaroid, I would definitely want to take a look. That's pretty extreme, but it's the case for everything. So it's just a funny thing to think about. Yep. Some more things that they talked about were the clarity,

which was what we said with the readability. Simplicity is key. And the density of expression. That part I took to mean that first, your naming has to be good, but is all your code there key to the unit test? Is there anything that detracts from it? So when he's talking about the density of expression, it's more like, does every line look like it's pertinent

to what your assert's ultimately going to be doing, right? I kind of took that to mean, though, that what he meant was going back to, and I don't remember which chapter it was, but there was a chapter that was talking about making your, it might have been the one about method length, about keeping your functions small and having meaningful names. And I kind of took this one, this point of density of expression,

as a reference back to that. You would have small functions and then meaningful names. And then that way, when you look at this small list of function names, you could immediately tell what you're trying to test. Yeah. One of the things that I liked about this chapter, and if you have the book, you can take a look at, like one of the things that he showed was one that was done sort of poorly, right?

Like it was extremely long. One of his own. One of the things that he showed was one that was done sort of poorly, right? Like it was extremely long. One of his own. One of his own. And, and he said, you know, I took that one and then I refactored it into this other one that was much easier to read, more concise. And, and I liked that he took that approach, right? Like he didn't just make up something. It's always nice when you can see a real world example of something where, oh, okay.

Yeah. I'm not perfect either. Right? Like this is where I started and this is where I ended up and it's, it's easier to follow. And you can see a real world example of something where, okay, yeah, I'm not perfect either, right? Like this is where I started and this is where I ended up and it's easier to follow. And it really was. And I should point out, you said that if you have the book, but if you don't have the book and you would like it, you should leave a comment on this show's episode, show notes. Yep. Slash episode 54.

All right, so our next section, I like this one. This was also, this was the build, operate, check pattern. So, yeah, I liked it, but I've heard this pattern referred to the AAA pattern. Oh, yeah, you've called it that uh the arrange act and assert pattern and so i like i mean as soon as i saw what he was doing i'm like okay i get it you build that's the arrange you operate that's the act and then there's the check pattern and then okay that's the assert But from a mnemonic, I just felt that the triple A was easier to be able to tell someone and explain to them and then have a higher probability that they're going to recall that versus whatever B-O-C-P might spell. I can never remember the triple A one.

Check pattern. Pattern. Okay. Triple A is Check pattern. Okay. AAA is way better. Yeah. It makes you feel like you're covered. No, there is a... Okay.

Sorry. The point being is that going back to the way some testing was done before the build, operate, check pattern or the AAA pattern was being implemented was back when it was the record and repeat type pattern. So you'd actually have to record. You'd have some software that would record what you're doing, and then it could replay those actions and those type of tests, you know, I mean, that's going back some time, uh, going back to our system clock there. Um, those tests were more, let's say brittle, uh, and, and harder to maintain because of, uh, you know, because they were literally just recordings and replaying, you know, some actions. Whereas now that we've gotten into this build, operate, check pattern, or, you know or arrange, act, assert, that pattern at least to me is definitely the popular pattern to

follow is way easier to A, write your unit test so that they're readable because then your future readers can see like, okay, this is the pattern where he's building up and arranging whatever objects have to be situated in a particular state that he's trying to test for the unit case. Then you can call out specifically what the action is that you're going to operate on that's the thing under test. Then there's the simple assertion followed by it. It's a lot easier not only to maintain, but I feel it's easier to increase the readability of it. And there's a great example in the book of refactoring a

root test to a clean one. So if you've been in the book, you should check it out. Yep. And he gets into this other topic too that was quite interesting I've never taken it to this level But he was talking about creating your own testing language A domain-specific testing language And one of the parts of that that I really liked Is if you're familiar with the give-and-win-then syntax Which I can't recall if we've talked about that before I know we've talked about frameworks that use them like Cucumber.

We've talked about Cucumber, I believe. We've mentioned it for sure. SpecFlow is another one that I know we've talked about. SpecFlow in a previous episode that uses the given when then. But he actually took this to another level, which was he was writing his unit tests in that given when then syntax. So he would have some method that would be given when or given and then whatever

operation he might have. But that was the portion doing the building of the state. And then the when would execute whatever the condition was that he actually wanted to verify the results of. And then his then method would assert. Yep. Yeah, and I definitely think of this toe in the line to BDD.

And when I first started reading about behavior-driven development, there was a lot of talk about DSL. And I think that was kind of around the rise of Rubyy on rails too just happened when i was looking into it and it was so easy to create dsls which really just meant a set of functions that looked like english um for at least the stuff i was looking at um that was a really popular way of doing things and it kind of faded out maybe just because i'm doing more dot netty stuff and less web stuff these days but i don't really hear too much about. But it was kind of a nice blast from the past

to read this section again. But yeah, the thought of like creating a whole new language to me just sounds exhausting. So, you know, things like spec flow and Cucumber where you kind of write a sentence and then, you know, you describe it and then you kind of take things down from there. And so that when you run your test, it looking like sentences that's really nice to have as output but you're not really running the tests based on that english even though a lot of the frameworks do support stuff like that i think it's kind of falling out of favor yeah i can say for my own unit tests, I don't, I'm, I'm not so much of a fan of having, uh, like private methods or just additional methods inside my unit test classes other than the tests themselves. So I realized that if your tests get extreme, then, you know, you might, uh, you know, your ear might've just thrown up

as you heard me say that. But, um, I guess what, like I try to keep my unit tests ideally down to like three lines, right? There's just the assert, the act, I'm sorry, the arrange, the assert, and the act. Now, occasionally the arrange portion might, um, be a little bit more, there might be, you know, a few more lines, but I, I, because I'm trying to keep it so constrained, then I feel like the given when, then it would just, it would muddy up my unit test with a lot of private methods that would be these one-offs of uh given some scenario um but maybe that would have actually helped me reuse scenarios inside my unit test but i just i don't i don't do that i think it really depends on how complex your setup is in a lot of cases right like if you if you have some fairly complex objects you need to set up then then maybe you break those things out i mean doesn't that feel like a code smell to you

though i don't know necessarily because i mean some things are just not easy to set up i mean if if we take something like an order an order system right and you've got orders order details and and maybe something else right like pricing information sometimes you have to set some of those things up in order to get anything meaningful out right so i could i could see definitely where it's not always just okay here's a three-liner and it's done i could see a situation where you actually have to have an order object and some order details the objects in order to even make anything make sense, right? I will say...

But then you... Go ahead. Oh, sorry, my bad. I was just thinking, Code Wars, the JavaScript problems are typically written, the tests are typically written in a BDD format. I forget if it's Mocha or Chai, I always get it mixed up. But it reads really well,

because you run your test and you'll see those sentences output. And a lot of times when you submit an answer, it'll run over 100 tests. And so it'll say like, you know, given a blank tree, when you add a negative number, it adds to the right or something. And so those tests just read really perfectly. And it's easy to find what you're what you're looking for. But I think that only works because the max number is probably 100. And when you're talking about unit tests for like an enterprise large solution, you're looking at thousands and you need better organization for something like that. Yeah. I mean, I think though, on the other part,

that's when you start looking into mock libraries and things like that, right? When you start having to get into setup that's not just a simple one-liner, there's other things that come into play. And so I think that's where you can start building on your unit test classes more than what you typically want, right? You typically want something pretty easy to set up. And the author used something in the book that was like an XML example. And that's a perfect example, by the way, because XML is dirty to work with in just about any language. And so he would have something where he would say,

oh, God, what was it? Given page one of the XML, when these elements are there, then assert that this element isn't there or something like that, right? And setting up that XML document for your unit test could be just ugly, right? Even in C Sharp, if you try to do it, even with link, it's not pretty and that's about the most concise way to build an XML document I know of, but it still gets super ugly. So I could see having helper methods for that kind of stuff. Yeah, I'm going to give it a try and see how well I like it.

Like I said, I haven't done that, but I will give it a look. But going back to your XML example of that being a great, I can actually, if you are not familiar at all with writing unit tests, if that's something that you've heard about, you know that you should do it, you just haven't found a use for it, or you haven't found a great place where you think it would plug in, I can tell you right away an amazing place that I think where it fits in quite well is if you have any regular expressions in your code,

you should write some unit tests to make sure that regular expression is handling every scenario that you think it is. Yeah, that could be fun. Yeah, and you're testing those anyway, so why not just formalize it, break that regular expression part out to a separate function? It's a great place to start,

and you should be testing it anyway, so why not immortalize those in a simple test? Yeah, good point. So there were some things that he made some interesting points on for me. And we'll get into this in a little bit, having a single assert versus multiple asserts. But one of the things he had is he had an example where there was a temperature that he needed to

test a bunch of different systems to make sure they're in the right state for that temperature right and so his asserts really did need to check multiple systems now you could have broken that out into i forget how many different systems he had, but let's say it was, let's say it was eight or so. If there were eight systems, are you going to break each one of those out? Yeah, maybe you could, but then you can't test the entire system as a whole. Well, one thing that he said was when he had his eight asserts in a row, it was kind of hard for your eye to follow saying like you know whatever it was the heat pump system was it was it true did it insert true was the you know some other sensor was it false and he said you it's real easy for your eyes to lose so one of the things he did

that that was interesting and maybe useful is he just didn't take an acronym he initialized every one of those so if it was a heat pump he made it an h well if it was an uppercase h then that means he assumed that it should be true in his assertion if it was a lowercase h then he wanted to be false so i'm kind of curious what's your thought on that? I thought it was a nifty way to do it. I actually didn't like that at all. I didn't think you would. Because then if, because, okay.

So the reason why is it kind of felt like, okay, so basically what you were describing is he introduced a new method for like called get state and it would return back this string representation of like, you know, upper age, upper B, upper C,

lower B, upper T or whatever it might be. I don't remember all the letters. But you get the idea is that there was like each position of the string had meaning and the case had meaning. And it was just like, okay, so we're introducing this method here that is only needed for these unit tests only because we want to simplify the reading of the unit test to be able to say hey does the current state equal this string and oh by the way

now you the reader of that unit has got to know what upper h upper b upper c lower b upper t means and it was like no no i don't like that. Yeah. I mean, it was interesting. I get it from somebody who'd be in the code all the time, but for a consumer of it, somebody that would be looking at that output, maybe on a build system or something, you may not have any clue whatsoever. I mean, and maybe if you had used for that state method elsewhere, you know, maybe in whatever your domain is, that meant something. so you were already going to have to implement that anyways, and you want to test it, then sure, fine, write a test or one or more tests around testing that thing. But for testing the individual

states, I kind of felt like those should have probably been individual tests anyways to test the individual state of the blower state or the temperature state or whatever it is right the heater state and that that's the interesting thing right like that's where i somewhat agree with what he did as far as putting all the asserts into one because for that temperature you want to check the state of the entire system as a whole right so i get it i understand it in in probably the most raw the purest form you would have broken every one of those eight we'll say out into their

own unit test right and you would have passed in that temperature so for every single temperature you're going to test you'd have eight of those so let's say that you had 10 tests you're not going to have 80 methods right as, as opposed to just 10. So I don't know. Maybe it gets to a point where it's not as useful when there's that many tests because it's just noise. But if your whole point is just making sure those methods pass properly, then you don't really lose anything by breaking it out into the 80, right? Yeah. It definitely increases the readability like

i said like trying to understand what that string is and coming back imagine coming back to that string three years later oh yeah right wait what does upper h mean right when that what is h yeah yeah so that that was interesting the one thing i did like here though in building his example because because he was doing this whole upper lowerlowercase thing, he had to concatenate strings. And I thought this was a great example of you want your code to be clean in unit tests, but it doesn't necessarily have to be performant. Well, let's say

he called out that there's a double standard for production code versus your unit test code. And the reason why I want to be careful on that, because I don't want to say that it doesn't need to perform it in that your unit test doesn't have to be fast, because it does have to be fast. So let's walk the careful line of performant. It doesn't have to scale to a billion concurrent users because that's not what you're trying to accomplish in the unit test.

Unit tests are not trying to test scalability, for example. In this case, he was doing string concatenation to put together these H's and B's and all that. And in real world, if you wanted the absolute best performance out of that in Java, it was a string buffer and.NET, you'd be using a string builder. And that's typically the way you'd want to go. Well, again, on, when you're running unit tests, you're typically on a machine that you're not fighting for resources. So that extra bit of

memory probably doesn't matter at all. So it's actually better for you to write it in a way that's clear to where you don't have all these string builder dot appends and that kind of stuff. Right. It's just easier to read. That's more important than the extra few kilobytes that you're eating up while you're doing it and i thought that was that was an awesome point out and it is that double standard but it's it's good to know and keep in the back of your head yeah so i mean you kind of hinted at it already but there is that um you know the philosophy that your unit test should have one assert per test now uh you know some might want to take that more extreme than others i know that i personally try to adhere to it but sometimes i'll have a second assert in there that might just be relevant to the situation. But then another thing that I will do too

is there are times where if while trying to do the arrange or the act portion of my unit test, I might have an assert just to make sure that the state is ready for what I'm trying to do. And then I'll even have a, this is the one, one of those few times where I will put a comment and I'll say like, Hey, look, you know, this isn't the assert

we care about, but if this assert isn't true, then this unit test isn't, or if this, if this assert, you know, situation isn't valid, then the whole unit test can't be trusted. So for example, let's say that, just to give an example, let's say that we had an array and we custom made our own array class and so we want to be able to test that the delete method of our array class actually removes rows from it. Well, maybe there's some complexity in getting that array state set up

to where it actually has some rows in it. So I might say, okay, let's assert that there's actually some rows there, that the current rows is greater than zero, because what I don't want to do in the assert that I actually do care about is say assert, you know, that, uh,

the count is zero because if it was never greater than zero, then what am I really asserting on? Right? Like, I don't know that the assert, um, that it is zero is valid unless I know that the assert that it had something greater than zero was valid.

Right. Right. And I know that's a really contrived example, and you're probably thinking like, well, that sounds like a stupid case. And, you know, I limit that. I don't do that. That's the exception, not the norm, of when I would have that second assert. And typically that assert, by the way, because I'll call out,

if you ever read any of my unit tests, I'm very particular about, you know, here's the arrange section, here's the act section, and here's the assert section. And usually, in an ideal situation, the act and the assert portions of that method are each one line. And, you know, but when I do have this, you know, like, let's call it the awkward you know assert um you know it'll it'll be you know depending on the scenario either in the arrange or the act um but it will definitely not be in that assert section because i want to make it clear to whoever comes behind me to read that unit test that the thing that i'm asserting is the thing at the end right i mean it was it was kind of interesting in that regard like what it boils down to is and i'll jump ahead just a touch here because we're talking about it is as long as your asserts are all in line with what the concept of that method is

then it's probably okay. Right? Like you want a minimum, you want to do as few as possible. One's the best, you know, and if you can do, if you can keep it to one, awesome. But as long as whatever you're doing is building up to what that method is supposed to be doing, and you're not testing any outside miscellaneous things, you're probably fine. And in the case, the author, when he was doing the XML thing, it, it, I felt like it was such a good example because on page one, he wanted to assert that certain elements were there because that, that had to make sure that yes, this is the valid XML page that we're looking at. And then his final assert was, okay,

now let's make sure that, you know, some other element was there or wasn't there, right? So it was literally just making sure, okay, yeah, the state is what we expect it to be. Now let's assert the real thing. And I felt like that was a fair example because he wasn't going to any outside thing and saying, okay, well, let's make sure one plus one equals two here and then let's get back to the XML, right? Like it was all very much in line with what the original concept was. Yeah and in thinking of it this way too that you know you know as a guideline we want a single assert right that like let's go ahead and just say that's the best practice but when we when we do need multiple asserts well a let's try to minimize minimize it and then b

you know it made me feel better that in that scenario, I could just say to myself, okay, well, okay, fine. I need a second assert here. But I'm still testing the single concept and that's okay, right? So I felt okay about that. It actually made me feel better about the times that I have had the double asserts. And again, I'm talking about double asserts in the assert portion of my method,

not in that other scenario that I described. So just wrapping up, ideally, we would have the single assert, keeps our unit test laser focused on that one thing that we're trying to test. And I actually have, as part of my tip for the week, I have some strategies that I was going to share related to that. Cool. Alright, I think we're actually getting close to the end here. This one was kind of cool. It was, they called it FIRST.

And so this was the acronym for for what your unit tests should be so i think maybe we round robin this i'll take the first one well these are the these are the five rules that your unit tests should follow yep so the f stands for fast your tests should be fast and run quickly who's next i'll go next your unit tests should be fast and run quickly. Who's next? I'll go. Next, your unit tests should be independent. They should not depend upon other unit tests. Each test should be able to be ran and executed in any order.

Have you ever had a problem with this, by the way? Have you ever done this? Or the opposite of it, I should say. Tests that depend on each other or a specific order? No, but I have seen them get called in different orders. I've definitely written some terrible tests that depend on the results from prior tests, and they're obviously not unit tests because they're depending on

state, but yeah, it's kind of funny things like have a test called create user, and it'll create the user and then I'll have a test that I'm assuming is going to run later that will update the user and then eventually one that will delete the user and so they're all depending on uh the prior run of another test terrible tests nice call out well you've got the r sir yep repeatable these should be repeatable in any environment without any specific infrastructure and i take this to mean too that the test should also be independently repeatable like i should be able to run the update

over and over and over yep the s self-validating they should have a boolean output pass or fail that's it output well just to expand on that what it means too is that like you shouldn't have to go and read a log file to see if that test passed or not or you should just be able to assert on one condition yep or you know maybe two right um and lastly well we covered that so i feel like i it'd be wrong of me to not not say it uh lastly is t timely they need to be written in a timely fashion just before production code is written and this is definitely a biased one because that definitely assumes you're following tdd right yeah which i mean following TDD. Right. Which, I mean, I don't want to get into TD. So in this episode, we talked about the three laws.

We talked about, first, the rules for your unit testing. We talked about a few things in between. Demand-specific languages and keeping your tests clean. Yep. And so some of the resources we like are, well, CleanCode.

We'll have a link to that up there. And I think we mentioned CleanCode for JS in the last one. We could leave it in there. We'll be nice, guys. It's relevant. I think it fits. It is relevant. And so now we're into my favorite part of the show.

It's the tip of the week. The tip of the week. All right. So Joe, what you got? I'm still trying to get mine on screen because one of your, one of you guys, I'm not saying which one has such a long tip that if you accidentally mouse

into the cell, it blows the whole screen out. So that's how good we do that anyway um i've got two tips of the weeks because uh i can't follow directions so i don't know why i'm giving a hard time but um these are two things i found about from our slack channel um one is glyph friend which is a visual studio plug-... Oh, I didn't ask how to say it. I don't know if it's Rihanna, Ryan. I'm sorry.

It's Ryan. Ryan, okay. Well, I'm sorry, Ryan. GlyphFriend. Anyway, it provides IntelliSense preview of icons. So if you're in, say, like an ASP.NET project and you start hiding your icon, it'll give you a little dropdown

that shows you the little images that you have to choose from. So it's great for search and discoverability and also just kind of um it's a great way of not having to flip back and forth between like the font awesome website or whatever else you might be using so just a really convenient um uh plugin and it's got like a bazillion downloads so you should check it out and the second one is from juggernaut with sixes instead of Gs. And it's a GitHub project called Learn Your Node, which is just a fantastic resource for learning Node.js via terminal. So you actually run this little program, and it's all kind of command line,

and it steps you through a bunch of different projects and teaches you different things about node.js and it's really neat and it's kind of retro and it's fun and you should do it that's really cool so mine is something i accident i literally accidentally did the other day i don't i don't know what i was trying to do but i stumbled on this so visual studio, and I've seen people do this at conferences, like somebody would say, Hey, could you increase the font size up there? And they'll just do something real fast. And it blows up on the screen. I'm like, Oh, that was really cool. I wish I knew how to do that. Well, now I do. If you hit control shift and then either the greater than or less than arrow, the less than will make it smaller and the greater than

will make it bigger. And it's amazing. Like you can literally just quickly bump up your, your font size so that you can either see more if you're presenting or whatever. So nice little quick tip that I stumbled upon. And you can also do that by mouse. So if you want to do control shift and then just use your mouse wheel, uh, depending on which direction you scroll, you'll increase or decrease the font. And then if you're like, you know, if you happen to stumble upon this and you're like, oh my God, what did I just do? Then in the bottom left of Visual Studio, it'll show you what percentage the font is currently set to. I hate the control mouse wheel, by the way. I don't know why. I'm always wheeling around inside my thing and if I accidentally

hit control, then all of a sudden my fonts are growing. It drives me crazy. Oh, is it just control in the mouse? I thought it was control shift in the mouse. It might be control shift. I use control shift a lot. So it's possible. Well, experiment with it then.

I might have been mistaken on that. All right. So like I hinted, I was going to give you one related to unit tests. And so there are a couple great resources out there to talk about names I'm not going to pronounce. One of them is Roy Oshirov.

I think that's correct. We've talked about his book before, The Art of Unit Testing. And then Phil Hack has a article on structuring your unit test. So Roy Oshirov has an opinion on how you should name your unit test. And then Phil has the opinions on how to structure it. And so what I've done is I've kind of taken these two great independent ideas and just mashed them into one uh which i think is like you know this is like the reese's

peanut uh uh uh reese's pieces cup or no uh the dang it what's the the never mind this analogy just went all kinds of bad yeah the the the buttercup peanut buttercup yes that's what i'm trying to say all right, that was a fail. You got to know your candies. Apparently, I don't. So that's going to get a laugh. So going back to the method naming, which is Roy Oshirov's opinion, is that you should name your – there should be three parts to your unit test method name.

There should be the method under test followed by some kind of delimiter, whether it be an underscore or, you know, which is what I would use. And then the condition, the actual use case being tested, followed by another delimiter, and then what the expected result is. So for example, let's say that we have a customer class and we have a method inside of that customer class called get full name. So you might write a unit test where the name is get full name underscore when middle name is blank underscore returns name as first space last, right? And then that way it's immediately clear just from reading the name of the method, A, what method you're testing, B, what use case you're testing, and C, what the expected result is. And so the developer who comes behind you and reads your unit test,

they don't even have to look at the body of the code to have an expectation of what that thing should be doing, right? Then Phil Hack takes it a step further where he says, okay, create your unit test class. So you create this customer test fixture to contain all of the tests related to that customer object.

But then inside of it, create inner classes for each of the method names. So inside of your, you would have a customer test class. And then inside of that, you would have a test class called get full name. And inside of that is where you would a test class called get full name. And inside of that is where you would have the method that I previously described, right? And then, so that way you have a class for each of your method names. Now you might think, well, that's crazy. But then depending on what your viewer is, let's say you're in visual studio, for example. Along the top of Visual Studio, you have three little dropdowns, right? And the middle one will allow you to quickly drop between the classes,

the inner classes inside of that class. And then the far right one will allow you to go between methods. So if you wanted to just focus on, hey, show me all the methods related to get full name, you could change that middle dropdown to get full name, and then your right dropdown would be just the methods there, as well as in your solution explorer, you could see something similar to that. And similarly, in an IntelliJ environment, you don't have the dropdowns per se, but you could see the same kind of structure

in your explorer when you are viewing these. And so I like it. I think it gives it a real clean way to reason about your unit tests, especially in the example that you gave where you have 80 unit tests or whatever. How do you make sense of where all those 80 unit tests are and like what they're each trying to test. And this way you can immediately just looking at the names, you can get an idea. And depending on what your test runner is, and especially true in maybe like a you know, I guess at least in my own experience where you know, when I was writing some Java and we were using

command line tools to run our unit tests, getting a report where you immediately saw the method name, then you already had an idea as to what was failing without requiring some nice UI wrapped around it like a ReSharper as your test runner or a.cover, right? It didn't require any of that. Just seeing the method name, you already had an idea as to what was broken and where to go looking for it, rather than having a test method that's named something like test one,

right? Or does this work or whatever. So I'm going to include a very skeletal version of what I'm talking about in my, you know, as to how I would structure this, as well as links to Roy and Phil's articles where they talk about these ideas. And then in that example too, I took it a step further in case if you wanted to know about like, if you really want to get into unit testing, then the beauty of using some of these testing frameworks specifically like in unit, for example, is that you could do parameterized tests and JUnit also has the same

thing. And parameterized tests are awesome because then you can just have a test case like attribute on your method and you could pass in the use case that you're testing as well as the expected result all at the attribute level and have one method

that might test multiple things. So we'll include a link to the in-unit documentation for both the test case attribute as well as the test source attribute. And I think we've talked about test source. I think that test source was a previous tip of the week

that I gave a while back. You first. All right. We've got some resources that we like. Unfortunately, they jumped off my screen. So I didn't realize that we'd already mentioned those. So there will be some great links

there on the blog post only once. But also I screwed up too and did this show somewhere earlier, but I'll do it again. It's because I'm

sorry. I ain't scared. This week we talked about chapter nine, clean codes, unit tests. And we hope that

the main point you kind of got out of this is that unit test code is debatably as important as production code because it allows unit tests. And we hope that the main point you kind of got out of this is that unit test code is debated, debatably as important as production code because it allows you to make changes confidently and correctly, and improves your flexibility,

maintainability over time. And hope you guys liked it. See? Yep. So with that, be sure to subscribe to us on iTunes, Stitcher, or more using your favorite podcast app and be sure to head to www.codingblocks.net slash review to find shortcuts to your favorite podcast aggregators and leave us a review there.

We greatly appreciate it. Yep. And if you head up to www.codingblocks.net, you'll also find all our show notes, examples, our discussions, even the latest community spotlight stuff that Joe Zach's been putting together, our latest videos that have been up on YouTube. I mean, there's a ton of information up there. So definitely visit us. Yep.

And send your feedback, questions, and rants to the Slack channel, codingblocks.slack.com. You can get our PO box address for sending those Slack channel, codingblocks.slack.com. You can get our PO Box address for sending those postcards at codingblocks.net slash swag. That's also where you can send your self-addressed stamp envelopes for free stickers. Make sure you follow us on Twitter at codingblocks or head over to codingblocks.net and find all our social links.

That's a great way to get free stuff. Man, that reminds me of people here in the South. When they say Costco, they're like, we're going to Costco's. I'm like, no, you're not. You're going to one. The internets. The internets. I will say, though, it is vitally important that you check both of the Twitters.

Yes, you do. And also, I don't think we mentioned, so so codingblocks.slide.com is our slack channel but if you want to sign up for it and you don't and you want to do it on your own you can go to codingblocks.net slash slack and go ahead and pump your information in there and you can come join in on the fun yeah we might have forgotten to mention that uh for a while couple here it seems like yeah we've had some more requests for it since. So, yes. Definitely hit us up on Slack.

We would love to chat with you there. Yeah, we're a lot of fun. If you're feeling experimental, we set up a Reddit as well, slash r slash coding box, where we've been sharing stuff that people have been making and sharing kind of just amongst ourselves. So this cool tight-knit community that we've got going on that extended from the hashtag I made this Slack.

If you want to see cool stuff that people are doing, you should go to slash r slash coding blocks. Is our goal there to be the one programming community on Reddit that isn't mean to everybody? Yes, definitely. We've got some great moderators. You can definitely get some downvotes quick in some of the other ones.

So we'll be a safe haven. We're all about uplifting. Yes, we really do. We will tell you your code is crap with a smile. That's right. Oh, wait. That's probably not a good slogan. Well, if you put an emoji on there, it's all good, right? Oh, yes. If you put a LOL, that makes everything happy.

It does. Laws make everything better. All right.