Programming Throwdown - Unit Testing

Episode Date: February 22, 2013

This show covers unit testing, a way to put your code through the ringer before you show it to your users. Tools of the show: JsFiddle and towel.blinkenlights.nl. Books of the show: The Lean Startup (Kindle: http://amzn.to/157xbEl ), (Hardcover: http://amzn.to/12HwaDp) and Ender’s Game (Kindle: http://amzn.to/VcfVtD), (Paperback: http://amzn.to/Wg32hx) ★ Support this podcast on Patreon ★

Hosting provided by Host Tornado. They offer website hosting packages, dedicated servers, and VPS solutions. HostT.net. Programming Throwdown, Episode 25, Unit Testing. Take it away, Patrick. All right, so I've been accused before, not necessarily on this podcast, but my friends of being eccentric. Okay.

So to continue my trend of eccentricity. And on the podcast, you're eccentric. Ah! Man. You've been accused. No, I've been accused. All right. So my newest eccentric hobby is taking film pictures and developing them myself.

That's pretty nuts. I guess film is kind of considered by many people to be dead, and long live the digital camera. And I do have a digital camera. I have a nice digital camera, an SLR, and I take pictures of it. I enjoy it. And so it got me thinking, like, I want to do something, like, different. I see these people, like, taking pictures and film

and, like, all this special stuff, and it's kind of crazy. Yeah. And I began to be very intrigued because film went away kind of when I was just coming into kind of understanding it, right? So like I was still, I guess, probably like in like middle school and early high school. And the first digital cameras that people had and were using started coming about. And so when you're that age and you're not into photography, like I'm sure I'd taken some pictures with the 35 millimeter camera or whatever and then just send them off to the lab and they come back and i always just thought this idea of like people having this dark room in their house like oh this is like really intriguing and like i would love to do that because it's basically chemistry so so

let me get started so you have a room that's completely pitch black kind of like a prison cell or something and then so you would think because that's always the image I had in my head. Yeah. But no, that's not the way it works, or at least you don't have to. So I came up with this process on my own, and then it turns out it actually has a name. It's called the hybrid process. Oh, okay. So the way this works is I got a really cheap plastic film camera, but it doesn't shoot 35-millimeter film.

It shoots what's called medium format film, which is five times bigger than a 35mm area of image size. So you can get really large negatives from it. But the camera is like this cheap plastic camera made in China. It's called the Holga. It's famous for being artsy, and it has only two settings. It has two different aperture settings and two different shutters, one shutter speed and then what they call bold where you can just hold it open

as long as you want. Which basically means your picture will probably be messed up. Completely white? Yeah, exactly. Which is what happened to me a couple times. So I got this film, I got this camera and I shot some pictures with it and I'm like, I'm going to develop, and I use black and white film because the development process is a lot

easier. And so it turns out the way that maybe it's always been this way. But what you need is you need a dark room to move the film from the camera to what's called the tank. So you have, like, this little tank, which is a black cylinder that has a lid on it and a very cleverly designed, like, funnel and center tube. And then it's called a reel where the film goes. So no light can get in even when you take the top off. So once it's in there – so you have to go into pitch black

and like take the film out and load it into this little, so much engineering. It's actually really fascinating. But in the pitch black, you put it in this reel and you do this like twisty motion and it sucks the film up into a spiral

with space in between so the chemicals can go in. And then you load it up into this tank. And everything's done in there. Yes. And so everything's done in there. So once you load it, then you can turn the lights back on and the film's just in there. And then you pour the first chemical in, time it, into this tank. And everything's done in there. Yes, and so everything's done in there. So once you load it, then you can turn the lights back on,

and the film's just in there. And then you pour the first chemical in, time it, dump it out, pour the second chemical in, and you do this until it's done. So I did it for the first time this weekend. Yeah, yeah, how did it turn out? You can look on my – I did it on my public Google Plus page, so people can actually see it. Nice.

So it's terrible. I only got, like, two what I would call, would call like actual images and then a bunch of blurry things and bad and then a bunch of like overexposed stuff because I was doing this the completely non-engineer way. Like I created all the variables at once. And so it was a new camera, a new process, new everything. Right. So I had no idea what I was doing.

It's pretty cool. I'm pretty encouraged. Yeah. So I got one picture that I thought was like good, and one was underexposed. So I've got some problems. I'm working through them. But this is fun. It looks like you were a sniper in the Russian front in World War II.

Okay, so you're looking at this picture of this outside of my house. So, yeah, I said it looks like a single frame from an old movie. Yeah, yeah. So part of that is my development unskill. Part of it is the fact that it's the film

and it's black and white and a lot of it is too dark but it was very fascinating to me and it worked first time. So what I did

was shoot the film, develop it, let it dry and then I scanned it on a scanner and I don't have a fancy nice scanner or whatever

but yeah, so I'm going to try to improve it, try to be better and I'm doing this not because it's cheaper or like i think it's more awesome it's just interesting to me to be more eccentric it's like chemistry yeah i always thought it'd be fascinating and i always like wanted to do it so i always i got my my cousins my second cousin i believe that's what you called

your cousin's kids i got my second cousin's a chemistry set and it said on there like what their big selling point was that you could eat everything in it. Yeah, because that's what I want in a chemistry set. I was like, this is the weakest chemistry set ever. So then we went and bought magnesium strips that day. I was like, I'm going to teach you kids real chemistry. It was a bomb. All right.

Oh, geez. Now we're going to. No, he doesn't mean that. He's just kidding. No, I mean magnesium strips, like for fireworks and things like that. Okay. Isn't that a firework? Anyways.

All right. Anyways, but I thought this was cool. This is my new hobby, new eccentricity. Pretty awesome. And we'll see if I make good pictures. I also have a new hobby, but it hasn't come to fruition quite yet. It's not a new hobby. It's just a new project.

Oh, a new project. Okay. Yeah, yeah. Okay, secret project. Yeah, secret project number four million. Are you going to be a multimillionaire next time we meet? Maybe. Well, we won't meet next time if I'm a multimillionaire.

Oh, you're not going to talk to me anymore? That's so sad. Not like that. Jerry, I'm not talking to you anymore. So on to tech news. On to tech news, we have Flat Pixels, which is actually sort of a blog post, an article on different design patterns, especially with mobile. And I thought it was kind of interesting. It actually goes over a bunch of different competing motifs in mobile.

And so it kind of talks about, you know, Apple's known for having that very texture-based feel. Skeuomorphic. Is that what that's called i think when you make something that's not real try to look like something real like you add like leather stitching on the side yeah yeah and you try to make it look like a real object yep so apple's notorious for that and they've almost according to this article at least they've almost overused it and now people are wanting something that feels more like i'm not in the real world so they want to take something that feels very more abstract.

And so you're seeing this shift. First you had this shift towards realism, and that's one of the things that made the iPhone so cool was because it felt like a real thing. And you have the Kindle, which sort of feels like real paper and things like that. That was sort of the trend. Or sort of looks, not feels, but looks like real paper with the e-ink. And now you're sort of switching back to this sort of Tron-esque,

let's go back to the very 8-bit retro blocky style. And so that has its own appeal. And so this person, I'm assuming, is a good designer, but at least they're an educated designer. I don't know anything about their work. Well-spoken maybe. Well-spoken, educated. It sort of discusses these different paradigms, and I thought it was a pretty interesting article, so give it a look.

Okay, so talking about whether or not you should use skeuomorphism? Well, it turns out everything is skeuomorphic in this blog, but they're skeuomorphic for different reasons. Oh, okay. So we're actually looking at two pictures from the blog post. The one on the left has just very solid flat colors for buttons. Oh, so it doesn't look like buttons. They're just squares.

Yeah, exactly. Whereas the other one has like a gradient and tries to look like a physical button. Yeah, so the other one you feel like it would have a bevel if you touched it. Interesting. And then they're going over, you know, which one's better. It's somewhat of familiarity, right?

Like if I have a calculator on my iPhone, I want it to look like my calculator so I know what to do. Yep. So in some ways, yeah, it has to be looking like real life. But it doesn't need to have, like if it gets in the way, like I don't need it to have the segmented display, right? Like just to look, like that's silly. I don't need that. Yeah, the other thing they talk about too is there's a trade-off so if you you might feel like i want it to look like the one in real life but on the flip side if it looks like the one in real life you also expect the

same limitations of a real life calculator interesting yeah so they actually argue both sides so the calculator on the left the one which just uses flat buttons, if it did something, some really high-level math, or if it took you to Wikipedia or something, you'd be less jarred than if the one that looks like a real calculator did that. Makes sense. Yeah. So it's sort of a really interesting article. And then it goes into Apple and Google and all the big Microsoft, all the big shots.

There are different UI techniques and things like that. So I thought it was a pretty good article. Yeah, okay. So the one I have is not like that at all. It's about a version of Minecraft that was released for the Raspberry Pi. We've talked about the Raspberry Pi before, the really cheap, small computer that runs Linux. And they released a version of Minecraft for it that's for free,

but it's stripped down it doesn't do everything or in the same way and I guess maybe I didn't know I'm trying to remember when I read it I think maybe also some of the source code or at least the ability to kind of extend it was released so people could kind of modify and do other stuff as well yeah there's scripting languages it looks like okay that's what it is yes all right yeah cool yeah so if you have a Raspberry Pi check it out play some minecraft minecraft's a pretty fun game do you play minecraft i did i played a little bit of it um i thought it was pretty cool actually i the coolest part for me

was did you have this thing where you could have a website constantly sitting in your server and then streaming streaming to the web so no so yeah my friend had this setup where basically we'd have this god's eye view of our town at all times on this website and so even oh you know even when you weren't playing with your friends you could watch your friends yeah or you could have it on one screen while you're building on the other or you could oh i see you could see what happened while you were gone i think the only interesting part of that would be to have it record over time and then be able to play it back really fast. Oh, yeah.

That would be awesome. That would be what I would use it for. Yeah, that's great. Okay. Yeah, so I played it as well. I haven't played it in a long time. Now I should. I just...

Yeah, it's a shame they didn't open source it or someone hasn't open sourced a version. I think it's pretty lucrative to open source. Yeah, that's true. It's too lucrative to them as it is. Yeah, we read another article where they said the guy made over $100 million.

Mojang Studios. So while we're on the topic of gaming, maybe you could use this in Minecraft, it'd be cool. But I saw some stuff recently and it got me thinking about virtual reality. So the Oculus Rift, which was a Kickstarter project, which is actually turning out, looks like they're going to do really well

and kind of deliver on their promise. But they're trying to make a kind of affordable virtual reality headset with the accelerometer that can tell when you turn your head. So when you look to the left, the view of the world pivots to the left. So it looks like you're there, right, the whole virtual reality. So I've used virtual reality goggles before, but they were really, really bulky. And at this point, I'd probably say really outdated.

Remember the Virtual Boy? That was virtual reality goggles, but you couldn't actually pivot. You had to look. Was that the one with the red vector drawings on the inside? Yeah, exactly. Okay, yes. That was so bad. It gave me this massive headache.

So this is way better. I guess so. So they have a demo where I guess they're able to, you know, integrate with a lot of the current games without much modification, which is really awesome. Oh, yeah, that's sweet. Somebody told me you could have done this for a long time because basically you send the models to the graphics card.

So the graphics library calls already know the distance to objects when it's doing its transformations. So when it does that, it can go ahead and just essentially do it twice and give you the 3d view Yeah, I did not know it's kind of like Yeah, it's pretty awesome. So this this goggles are like people are like wow like you see people in the video It's like oh this is amazing and it's hard to get over like the way we're used to doing input So the way they have it now it's kind of like the goggle is mapped to what it would be your mouse in like a first-person shooter so if you you know turn your head to the left and then you hold the W key you start going in the direction you're looking and so I guess people

have a little bit of trouble with that but it seems like you'd get used to it pretty fast but I really want to try it like I told like watching a video is like this is not doesn't do anything other than makes me want to try it I don't know they want to buy it yet but makes me want to try it. I don't know that I want to buy it yet, but I definitely want to try it. Yeah. Do you know if 3D TVs have caught on? I don't think they've really taken off. No, I don't.

I don't know. I feel like the coverage of CES was saying like people kind of gave up on like, I guess everybody has 3D TV. It's another thing. You can't not have it maybe is the way it's going. I don't really know. But they're going to other stuff now, like other novelties. Cool. But yeah, 3. I don't really know. But they're going to other stuff now, like other novelties. Cool.

But yeah, 3D TV doesn't strike me. Like, I don't want to sit in my living room when I'm doing other stuff, wearing funny glasses and looking at the TV. Yeah, exactly. Like, me personally, I'm not saying I don't understand it or appreciate it. I just don't want to do that.

But gaming, that's different. Yeah, exactly. I mean, a game is made for one person per terminal. A TV is made for many people per terminal. And in this case, like, just personally, like my wife and I, we almost always watch different shows. But we'll watch each other's shows to keep each other company. So for a given show, one of us will be paying half attention, right? And so to have to wear 3D goggles would just make it just a really painful experience.

Now, what if you could like, so you talk about the Ouya. What if the Ouya had virtual reality goggles? Oh, man could like both wear them oh that would be insane we would just uh we'd we'd be angry i feel like you would just like run into each other angry birds you thought like the we people throwing the remotes through the tv oh yeah that was just imagine just imagine people standing up um on their my friend connect and virtual reality goggles would not mix. My friend accidentally uppercut his dog like Mike Tyson's punch out style, like almost jumping uppercut because he was playing Wii bowling and the dog just happened to walk in the way.

And that dog flew. It was rough. We were really concerned. But the dog ended up okay. So, I mean, would you get virtual reality goggles? How much would you pay for virtual reality goggles? I'd have to try them out i mean there's the variance is tremendous but like okay let's say they were like let's say they were everything not like mind-blowing not like oh but like wow this is really enjoyable like i can totally wear these all the time like what would

you what would you think about it so a playstation 3 controller costs 60 right so you'd pay at least that for virtual yeah of course you'd pay $60. I guess I'm low-balling. Yes. I was thinking like $100 tops. Well, but I mean, there are essentially two TV screens in your eyes. Oh, yeah, I guess that's true. I mean, it's at least two cell phones

worth of technology in your eye almost, maybe. I feel like a cheap cell phone screen would be like, you know, maybe like you'd expect like $100. I feel like it'd be at least a couple hundred dollars, right? I guess so. Do you know how much it is?

Yeah, I have to look how much the Oculus Rift was. Actually, you can pre-order it. Okay, how much is the pre-order? It is $300. $300. I mean, so that's still a good price, but that's way more than you were thinking. Yeah, you're right. So, would you pay $300 for it?

Maybe. Yeah, I'm on the fence. I mean, I'd have to try it because a lot of these 3D things kind of give me a headache. Yeah. If it didn't do that, it's a tough call even then.

See, I feel like I want it. Like, I would really like it, but I don't think I'd... $300 is too much. Yeah, yeah. I'm kind of in the same boat. Maybe I'm cheap. Yeah, I think we're both pretty cheap.

All right. All right. Interesting question. So the price will not... So it not only has to do really good, but it has to in the same boat. Maybe I'm cheap. Yeah, I think we're both pretty cheap. All right. Interesting question. So the price will not only have to do really good, but it has to get the price down as well. Yeah. I could see them going to $200 because the $300 also included a development kit.

Oh, ooh, interesting. Yeah. I don't know. All right. Tool of the show. Tool of the show. Okay. My tool of the show is JSFiddle.

Is this like where you play the fiddle in JavaScript? That would be pretty awesome. I should look up for something like that. Something that teaches you to play the fiddle. All in JavaScript. All in JavaScript. Using that HTML5 audio. In ASCII art.

Oh, man. We'll get to that. But JSFiddle, it's pretty cool. Basically, you can write some JavaScript, and it has a little drop-down where you can choose any of a number of frameworks. So if you like jQuery, if you like AngularJS, MeteorJS, whatever you like, it's an option. So you set this option, and it gives you this four-panel setup where one of the panels is the output. The other panel is, I think, HTML, and the other the output the other panels I think HTML and the other one is JavaScript or it's I think CSS the idea is with one of these you know with one of these

types of files with one HTML one JavaScript and one CSS you could effectively do anything simple and so it's an IDE sort of it's actually. It's actually meant for showing things off to other people. So you might have this cool JavaScript rollover or you might have this interesting way of binding data or you might have this cool little neat thing that you want to show people. And rather than use something like Pastebin, which just pastes source code, you can actually type it in this JSFiddle or copy-paste it, and it will show you the output. So, for example, I wanted to do something where when you clicked on a button, the page actually slid off the screen,

and the page that was meant to replace it slid in from the left. And somebody wrote a JSFiddle to do this. So you just give it a couple of divs in HTML, and it'll handle the sliding and all that. And it worked really well. And you could really test things quickly. You could iterate quickly. As soon as you change some of the code in one of the panels, the fourth panel refreshes.

So it's kind of a neat little tool. I think I need to do web development, because I have no idea what I can't picture this in my head. Oh, man. Well, it's not working. Imagine a page with text on it. Yeah, yeah, yeah. No, no.

And a little button with an arrow. When you hit the button, that page actually physically slides. Physically. Electrically slides off the screen. Electric slide. Do, do, do. Okay, sorry. I'm derailing this, but seriously.

It's pretty cool. This sounds cool. I think I need to, like, I think visually I have to go see it. So, all right. But if it's to me, then it's not going to be looking at it and telling you isn't going to be very fascinating. So we'll go to mine. So mine, I feel like I can do a good job of having you visualize this in your head. But if you go see it, it'll be so much more awesome.

Okay. I was just showing Patrick a JS fiddle. So it's not the thing. It's not these panels that's JSFiddle. It's this site that people can give you snippets. Yeah, that's it. And so notice how when you scroll and you get this progress bar? That's the thing they added.

And so if you want that on your site, you could just leave it. Oh, so it's like a library. So you, oh, now it's, okay. Alright, it wasn't a web development problem. It was Patrick's brain problem. Alright, so mine is the awesome, amazing thing. And I think I've seen this years ago, but we're talking about it today

because somebody had posted an IP address that if you do a trace route to it, the host names give you the introduction to Star Wars. Nice. Which is pretty nerdy. And I guess they don't actually have that many computers with those host names. There's some trick that they do.

There's a couple different ways to do it. But you do need a lot of IP addresses, I guess, to do it. I thought that was interesting. It reminded me, and I found it, there was a website you can telnet to that does an ASCII animation of the entire Star Wars Episode IV movie. So like the first, the beginning with the words. Yeah, scrolling up and the first scene, you know, with Princess Leia on the ship and Darth Vader coming in.

And I started to show this to Jason, and he began to say, okay, how long is this? I'm like, I think it's as long as the movie. So I think literally every scene, it goes by, even like the opening parts or whatever. And so it's really fun. If you've never been there, you can look on the website it's tal.blinkenlights.nl

with a K I don't think you're gonna you can search for it Telnet Star Wars Episode 4 but I guess somebody had created ASCII animation for the whole movie in like a flash thing or something and then somebody got all of that and set it up on a Telnet server but I haven't watched it so I can't verify

that it's the whole movie but I'm pretty sure it is yeah i mean we had it up for while we were preparing the show and it was up almost the entire time and it did not look like it was going away i mean i literally think it's the entire movie at time scale so yeah so check it out it's pretty fun funny i don't know interesting yeah so you should definitely go see it it's uh it's pretty cool it's not exactly a tool but that's totally awesome that that's definitely worthy i feel like i need to do this kind of stuff like i feel like i'm such a slacker just thinking that i mean we should we should do something i just don't know what but uh but yeah that's that's pretty awesome it makes you feel like like you're being lazy because you didn't you know this is pretty epic achievement.

Although, I mean, the guy who drew all of those ASCII frames, like, I don't know. Yeah. I'm not sure. That seems like I would give up after the first scene. Yeah. I'll be like, how do you draw this bun on Princess Leia's head? And then just the outside movie staring at me. I'd just give up right there.

So it's pretty awesome. This guy did not give up. He made the entire movie staring at me. I'd just give up right there. So it's pretty awesome. This guy did not give up. He made the entire movie in CalNet. Or at least the internet says. A lot of it. At least the beginning.

The beginning half an hour. There's too many caveats. It was pretty epic. You guys should check it out. Book of the show. Book of the show. Our newest segment. Is that our newest

segment? Oh, yeah. That's right. Our newest segment. Unless the question of the show. think it's our newest segment. Oh, yeah, that's right. Our newest, our still newest segment. Unless the question of the show. But we didn't even do that. Okay, stop. All right, book of the show.

Book of the show. So my book of the show is The Lean Startup. And it's a book that a coworker recommended. It's about dieting? It's about dieting your company. But I don't really know what that means. So like working at a startup and staying and staying lean yeah exactly from a process standpoint so it's pretty cool stop the lean startup it's basically it's from a

guy who span off a lot of startups for people who don't know who aren't from Silicon Valley or from a similar area like Seattle or somebody has a lot of startups. A startup is effectively a group of people, they're usually called the founders, who have a new idea, something novel and interesting, and they want to take a risk on this idea that most big companies wouldn't take. So for example, you know, if you want to make some kind of crazy video game where it's a crossword puzzle, but based on Google Maps and you play people in your city or something, right? You know, most new companies, they like doing things that are sort of tried and true or they like buying startups that succeeded, right? So they'll pay the extra money to buy something that's already a good idea. If you have a brand new idea, often you have to, you know, spin off what's called startup and try and tackle these ideas and find out what value there is there. So it turns out that, you know, going from a cool idea to something real that is sustainable and a real business is an art form. And so this guy who's

done a lot of that and has a lot of experience shares that experience in the book, The Lean Startup, and talks about what it's like to deal with team dynamics and all about being able to capture information. So the first time you try it, you might make a crossword puzzle and the system can't handle the load and dies

and half the people who play it have this major complaint of one or another. And the whole thing might be a flop and you might have to scrap the whole thing but you still learned a lot from that entire experience and being able to to learn quickly so that the next thing you make can be that much better and being able to make sure that you learned everything you could learn from each iteration of your product is what most of the book focuses on. I think it's a pretty awesome book. I'm almost done with it.

And yeah, I definitely would recommend it to anybody. I feel like that minimal viable product, that's where this started, right? This guy's the guy who popularized that idea. Eric Ruiz. Yeah, the thing which you can build, which somebody will pay for. Yep. Get to that really soon. And he used some examples. One is Zappos.com, which is now a huge site that sells tons of things.

It's owned by Amazon now. Oh, really? Yeah, I believe so. It's still pretty big, even though it's under the umbrella of an even larger company. But the idea with Zappos, it started as just a way to buy shoes online. And the way the guy actually started, he had a little bit of experience with shoes but not much he's mainly a software guy he actually went to the stores he took pictures so he went to you know Macy's and even Walmart and Target took

pictures of their shoes with his camera put the pictures on his computer made the site Zappos as if he was selling the shoes with a little bit of a markup. And then people would buy the shoes. He would go to Walmart and buy the same shoe and then ship it to them. So he wasn't doing any of the distributing or anything. And that's actually how Zappos started.

And that was the minimum viable product. Now, the reality is with Walmart or Target or wherever he was actually buying shoes from doing all of the distributing and warehousing he didn't make a lot of money. In fact he probably made no money but he developed a huge audience of people and he showed that this was a successful business that people would buy shoes online even though they're worried about sizes and things like that. So he had to deal with a lot of issues. And rather than try and get shoemakers on board and do all this craziness, he just said, forget it.

I'll buy the shoes myself and ship them to them, and I'll still learn a lot about selling things online. Because he wasn't initially interested probably in learning how to wholesale and warehouse shoes. Right, right. Yeah, and so being able to do the part that's interesting and cool without the things that you might think are required is a big part of the book.

Interesting. Yeah, it's super interesting. Yeah, check it out. Someone else had sort of a Q&A site, kind of like Yahoo Answers equivalent, and he actually answered almost all the questions personally under a bunch of synonym accounts until it got bootstrapped. And so this whole thing is very fascinating, right?

Wait, did he also ask the questions? That would be taking it a step further. Maybe. Maybe he seeded it with a bunch of questions that he then answered. But, yeah, just, you know, how many times have you gone to a site and it's completely empty, right? Not very often. Like a forum and there's, like, three posts.

Oh, well, that happens a lot because it's just forum code that someone's duplicated. But I'm sure that even when the first person went to Yahoo Answers, there were probably a bunch of internal questions and answers maybe that were there. There was content. And so the whole thing was fascinating. I think it was a great book. Yeah. All right.

Well, my book, continuing my science fiction and fantasy recommendations, is Ender's Game. It's a classic. If you haven't read it yet, you should go get it now. I believe they're now turning it into a movie, so it's almost going to be ruined and not cool anymore. Oh, when's that? I don't know. I think they already started filming it. I'll have to read it again before the movie.

Yeah, me too. I really like this book, though. It's considered a young adult book, I believe. So, like, I think, you know, even younger kids can read it. There's nothing super violent or bad in it. But it's a really good book about, you know, kind of like a misfit boy who, you know, is like kind of the unlikely hero of a story. Kind of that is the trope it plays on or whatever in a way. And, yeah, it's interesting.

I like it. It's a classic books, you know, probably 20 years old now, 30 years old. Something like that, yeah. And so it's been out. A lot of people have read it, but it's got space in it. It's got technology in the near future, not distant future, but like kind of near future. And it's got aliens. Yeah, it's pretty

epic it has all the okay this is actually pretty hard so you can talk about the lean startup book and like talk about what's in the middle and the end and what it talks about but i feel like if i talk about that i'm just gonna ruin the book so how do i like i feel like i need to just go on a website and like read the summary of the like the back of the book yeah because if i say anything more people are gonna like be mad very tough not to spoil it's true but but you you uh you can always read the back of the book so you know we should do we should do ourselves justice by by putting her own spin on it but yeah okay all right I think it's a phenomenal you read it I've read it a long time ago okay so my so there's actually like I

guess there's many of the books in this world I guess right so this is the first book and it's standalone so if you just read it and end like, I guess there's many of the books in this world, I guess. Right. So this is the first book, and it's standalone. So if you just read it and end, like, you, I mean, that's fine. That is not a problem. But then I think it's a series of five books going forward. So there's four books that follow after this book. And I can't talk about what's in any of those books because that would be a spoiler. But then also there's other books where they, and I don't know, these are much newer books, but they go back and revisit. They kind of start all the way over again.

They reboot the series in a way. So it's the same storyline, but it follows other characters who were in that story. And it's like from their point of view. So they're the main character instead of the main character of Ender in Ender's Game. So it follows them and kind of what was happening while that storyline was going on. And so those are the shadow books. So there's like ender's shadow and then other people's shadow and so uh even for people who have read that sometimes they don't know these other books have been written and are still being written i guess like i think he might still be working on it

wow but overall like those books are really good as well in fact some people say like people i know have said they enjoy that those books more than the Ender's Game book. Oh, okay. But you probably would have to read the first one, right? Oh, yeah, yeah. I think you should start with Ender's Game and then read through it and then go back and read The Shadows. Yeah, but, yeah, the book is awesome. I believe it's one of these things that will become a classic and become a required reading and things like that.

It'll be, like, the next Watership Down or Pride and Prejudice. No. You never read? Oh, I know which one. uh count of monte cristo you must have really thought everybody in florida i mean i know i know the story but i don't it wasn't mandatory reading no wow i don't think so did you go to a private school or did you go yeah oh that's why okay okay it was required in all public schools in florida anyways okay tangent but basically yeah, The Ender's Game is an awesome book and is a classic or will be. Oh, here we go.

Here we go. This is a good line from the Amazon review. Here we go. It says, The futuristic tale involves aliens, political discourse on the Internet, sophisticated computer games, and an orbiting battle station. Awesome. Yet the reason that it rings true

for so many is it's first and foremost a tale of humanity a tale of a boy struggling to grow up into someone he can respect while living in an environment stripped of choices yeah you know i feel like a lot of reviews say these kind of things where the bigger issue is insert metaphysical you know revelation here and oftentimes it's kind of lost on me because i get really into the surface of the book so i'm really into you know as we talked about this book space battles and things like that and the things that are happening to him very directly and um um it's hard to get the bigger picture but i think this one sort of punches you in the face with the bigger pictures. Do you think so?

Okay, so I'm of the opinion, and this is me. So do you know the story, The Emperor's New Clothes? I think I had to read that as well, but it was a long time ago. No, I think it's a story. I don't know if it's actually a book. So this is a story about the, I'm just going to paraphrase and skip all over the place, but to get to kind of like the point of the story is that there's an emperor who's very proud of himself and this uh

crook comes and basically tries to sell him clothes but it turns out he's not actually selling him clothes he's just pretending to make him clothes but the emperor is really naked because the guy didn't make him any clothes and so the emperor's parading down the street in his new clothes which oh if you if you know what's fine and you're fancy, you'll see the clothes. That's what the guy kind of tells him. So he's like, oh, of course I see these clothes. These clothes are beautiful. He parades down the street naked.

Everybody having heard that, like, oh, if you know what you're talking about and you're able to have – you're of good heart, you'll be able to see the beauty of the emperor's clothes. So everyone kind of also says, like, oh, yeah. And finally a little kid goes, you know wait you're naked so this is like the story the emperor's new clothes or whatever so i'm kind of like about some of that stuff that people say i believe there are some authors who say like oh i want to tackle this issue and i'm writing this story i think other authors just say like let me write this story like i want to write a good story and then people like try to build all this stuff on top of it and make all these assumptions. Like the author is trying to say this.

Wait, maybe the author is just saying, what's most interesting to write here? And then it's less of a commentary. And I've heard authors who kind of go on both sides. But I think sometimes some of these things fall into – and this is off topic and tangent, but it's okay. So I think sometimes I call it emperor's new clothes. People get into like, oh, the book is commenting on this and that and the other and it's like you see this you would you would see this if you read it and it's like oh yeah yeah i see that too yeah then you feel yeah you feel like uh peer pressure right to agree with everyone but yeah

i feel even more so with art this lady will be like this lady will say oh you know this red color really means that he was angry at this point like maybe he just had red maybe red was on clearance come on you know but it doesn't lessen the work right like you can still enjoy it as a piece of art or like as a book it's just sometimes i think yeah yeah i think people try and take it too far so that they can iconize that that iconize wow that particular word. And so they want it to be unique. They don't want someone else to basically copy that style.

So they say they attach all this feeling and sentiment, and then you assume, oh, only one person. This other person can't have the same feeling as this guy. Yeah, I think sometimes reviewers, like that Amazon review saying, like the first part was cool, but then the second part, yeah, it's kind of like we're being extra insightful. Yeah, yeah. Read this book.

It'll change your life forever. Like, okay. Yeah, exactly. All right. So this show is on unit tests. So to understand unit tests, maybe we have to step back into our time machine and our futuristic traveling science fiction episode. That's right.

And look at the history of testing. The history of testing. Yeah. So first there was a guy sitting under a tree, and then Apple fell. And you learn next time to build an umbrella. I don't know. But the idea is, you know, Patrick and I are big fans of unit testing, myself especially.

And, you know, this is one of these things that even when I was in college, I don't know about you, but I always thought testing was kind of for suckers. And it's one of these things that sounds cool, kind of like proofs. My code always works the first time. Exactly, yeah. I mean, it's why- When I write it in assembly. Yeah, yeah. I always knew that.

You knew that kid in college? It was always that kid in college. I write all, I don't do Java. This is stupid. I write all my code in assembly. And it always works the first time. Oh, no. So, yeah, I mean, that's the thing.

You feel like, oh, you know, doing tests is like doing proofs. You know, the reality is, you know, at least in machine learning, I'll say, I can say with authority that almost all proofs are BS right the reality is most algorithms require some kind of fudge factor or a bunch of knobs to turn and you have to kind of get that right and there's all sorts of corner cases where the algorithm fails right the algorithms that provably converge are useless and things like that and so I kind of took this um took this sentiment over to unit tests and said it's one of these things that's cool to talk about in class but

we'd never use it, right? Turns out that unit tests, as we'll see from their history, have evolved to the point where they're now extremely useful. So the very first unit tests, they call this the the era before 1956, the debugging period. And the idea here is if you said I was writing a test, what it really meant is you're running your program and trying to see what happens. Okay. Looking for the failures, the bugs. Yep. All right. So what was the next period? The demonstration period. So this was, you know, testing was, I run my code and did it do everything it was supposed to. Yeah, exactly. So you have a list of, oh,

maybe you have some golden file. Like the code should output 1, 2, 3, 4, 5. And you just check the output of the file. I run my GUI. Do we have GUIs? This was 1978. Yeah, I think they had GUIs. Maybe. Yeah. Okay. You run your program. Make sure it does what it's supposed to. And then that have GUIs, this was 1978. JOHN MCCUTCHAN- Yeah, I think they had GUIs, maybe.

Yeah. DAN GALPIN- OK. JOHN MCCUTCHAN- They definitely had GUIs. DAN GALPIN- You run your program to make sure it does what it's supposed to. And then that was followed by? JOHN MCCUTCHAN- By the destruction-oriented period. And this is where people felt like testing

should find errors. So the idea is, in this phase, your code would compile, and then your code would test, and then your code would run. So you would write tests that would do things like run a function and give you an expected result. The very sort of what we consider now is the simplest possible unit testing was started around the late 70s. So you try to break your code. You try to give it stuff that will make it fail. Yeah, exactly.

So then there's the evaluation period. And this sort of takes it to a higher level. This says that testing should actually measure the quality of your application. And this went on from around 83 to 87. And so the idea here is maybe you're writing a bigger app or a distributed app. You have many users, things like that.

So you want your testing system to sort of be more reportive. Maybe you, every now and then, are in a situation where something fails. You're writing big apps, which parts of that fail constantly, let's say. You want to just get an overall feel for the quality of the app. So is it performing 90%?

Is it doing 90% of what I want it to do? Maybe you have these two or three features features which are either completely broken or semi broken but most of the apps operating the way you'd expect. And then now we have the prevention oriented phase and so the idea now the sort of mindset for people writing tests now is that the point of testing is to sort of detect and prevent faults from occurring in the system. So this involves sort of an amalgamation of everything, all of the other periods combined. So testing should be part of your runtime framework. It should be something that you do almost as an extra compilation step and everywhere in between. So a unit test, I mean,

we say it a unit, but what's a unit like i guess that's subject to definition to different of differences of opinion of what a unit is so i worked a job once where unit testing was like kind of what we talked about in the history here that you run your program and it runs on a set of input and produces a set of output and that your unit testing your thing right your program your whole program you know it's some or or your output, and that you're unit testing your thing, your program, your whole program. Or at least you're testing a whole set of classes and stuff all together at once, and you're testing that they do exactly what you define.

And that was unit test. But I don't think that's what unit test is really supposed to be. No, that's a good point. So we're covering unit tests because testing itself is as big as programming. But there's also other types of tests so there's regression tests so let's let's kind of break them down so are we gonna try to all of them no no we won't cover all of them I'll take forever but we'll give a one sentence of each of them unit tests are at least is my opinion and you could

you know feel free to correct me your wrong ideas off unit tests it. Unit tests are testing, for example, one function. You have some function foo, and it's supposed to take A and transform it to B. And you call foo a bunch of times with expected Bs, and you give it some As and expect Bs, right, for foo. I would diverge slightly because I think sometimes that can be an overuse of unit testing to say every function needs a test, and I've certainly had code that does that.

Oh, that's true. But it's like the smallest something of which has meaningful test results. Yeah. So in other words, if you have something which isn't doing any decisions, it's not doing any kind of math, it's just like very, very basic function, like a get method. Right. Some people are like, oh, you need to unit test a get method.

Well, I mean, if there's a problem there, you've got worse problems. Now, a set method, if it's doing some sort of checking, that may need unit tests. But in general, like, oh, you know, writing a unit test for just a simple set and get method that doesn't have any sort of balance checking or any of that, it's probably overused. So saying function,

maybe not. Maybe you're calling another function which calls that function. Yeah, so there's another point about coverage, which we'll cover later. But yeah, that's totally true. Another thing is other than unit tests are regression tests. And these are a little bit larger. So this gets to what Patrick was saying. But that's not a size change, though.

Next thing would be to maybe go to a system test or an integration test. So like going up the scale. This is interesting. So you can kind of like go up different dimensions, right? So like you can go from like a unit test to like testing multiple units together. That's regression, right? No, an integration test. Oh, it's integration, right.

So you're integrating multiple things together and multiple. And then you get to like your whole system, which is composed of subsystems and parts. And depending on the size of your project or the scale you may have many levels in between you may define them differently but then the system test is like kind of testing the whole you know everything all up together that it runs it you know given an input there may be many many many many many calls down and back up and decisions and then and then it returns something and you're testing the whole system at once. And that's kind of where you typically, requirements are written against the system.

And so you're testing that you meet all the requirements. So what's a regression test? So a regression test is you have the system test, and now you change something in the system. And your regression test is you test that nothing changed between the two if it wasn't supposed to. So I run the system test again, and then I

check that nothing changed or it changed in the way I would expect it to gotcha so like if so I worked once doing some banking software and when you do banking software they really want to make sure that you have a whole suite of regression tests what that means is you run the suite of pro tip people banks don't use floating point that's true so. So it is all fixed point math. Yeah. And so you take the numbers and you run them once, right, and like with your current system. Then you want to apply this change. But you need to prove that the change doesn't break some of these core tests.

So it's not so much – that's why I think it's a different dimension because you're not testing more or less. You're testing it from point A. Like time interval zero, now at time interval one, do my results match? Or can I explain why they don't? And that's what a regression test is. I always thought a regression test was an integration test. I don't know why.

I just never really thought of it. I might be wrong, but that's how I've always defined it. No, no, no. It makes a lot more sense. I mean, I know it makes more sense given the word regression. Regression, like have you regressed? Do you want to prove that you haven't made something worse yeah yeah exactly right so okay so there's integration tests where that's more for where you have say

a set of functions and you have expected output for that functions maybe that output is in a file or something like that but it's it's not the typical output your your system might not deal with files it might be some web service but you have an input file and an output file just to test this core piece. And so that would be an integration test. Then as Patrick said, the highest level is a system test where if you're making a website,

you would actually have, so there's something called WebDriver, where it can actually start up Firefox and click buttons and tab and type things in input boxes as if a real human was doing it and so that's the highest highest level in the in the pyramid right so system test is where someone's literally you bring up a test server with your website on it and then this motor this computerized agent goes on and type some fields in and registers an account or something like that

and that whole process should succeed so then you can get into even another dimension you get black box white box testing so black box testing may be like oh you bring up the fake version of firefox you type this stuff in then you try to log in once you've created an account and you make sure that works because a black box is treats the whole system as a black box so I don't know anything about it. So this could be done by an outside person, you know,

a contractor who's not working on developing the source code. It could be done, pretty much should be by anybody, right, who just understands how the system's supposed to work. But then other tests

like unit tests can only be white box tests. Oh, I see. Which means you have to know, you're testing something specific on the internal. So like a white box system level test

may be like, oh, I create an account at the form and then i go and check that it's in the database oh i see right so like now i'm doing white and then there's a gray box which is like in between and like this is kind of trying to treat from a different uh different look at the system oh in a different way i'd never heard that either so for people who have if it isn't completely opaque patrick is way better at testing. PATRICK MCAVENALEE- Whoa, whoa, whoa. I don't know that's really. Hang on, hang on.

But so I think that one of the kind of ideas, there's many, many ideas in many different sections. But one of the things about unit testing is if you kind of go down and you say, I'm testing the lowest level, and I'm making sure that that's correct, then you can build up. Because then when you do an integration test, you're not trying to retest what you tested in the unit test. Right.

Which is a common mistake. I think when I was starting out, that's what I did a lot. Like, oh, I need to retest at the same thing, like run the same test. But you don't really. What you're testing is interfaces. So I assume people have unit tested each of their individual parts. And now I need to test how they interact together. Right.

I mean, if you think about it, if, I mean, the entire test suite is meant to be run, you know, as one unit, right? So if your unit test tests this function and then your regression test tests the same function, then you're just kind of wasting your time. So, yeah, you don't want to write an integration test, which is... An integration test, yeah. I said a regression test. Oh, sorry. integration test yeah i said regression oh sorry you don't want to write an integrate for instance like like you had an rpc a remote procedure call and you know has a client and a server and then it executes you know some of these two numbers together you don't want your integration test to have the purpose of i'm writing an integration test which has the client call the server with the numbers one and one and then i get back two right for the purpose of testing that that bottom

function is doing one plus one equals two. I mean, you do need to write probably a test that, you know, make sure that you get back the right answer. But you don't need to go to all the corner cases of the bottom most unit there. Yeah. You need to test all the different ways of calling. That's what you need to be focused on. So, I mean, a better way to do that, just to finish Patrick's point, is you could make

the RPC with one and one, and you could make the RPC with one and one, and you could call the function directly with one and one. And in both cases, you should get the same answer. And the nice thing about that is, I mean, in the case of adding, it's obvious, but let's say you change that function. Like, let's say one and one really is now equal to three. For whatever reason, that logic has changed. You don't want to have to go back and change your integration test to change a 2 to a 3. You want to change your unit test of that function, and then the integration test should still just work fine. So that's how you kind of build up.

But unit tests themselves, let's isolate down to this or else we're going to spin for a long time. So we kind of talked about one of the things that you... there's this very beautiful notion in computer science of getting to provability like i want you know i want to treat my algorithms like math and i want to be able to generate proofs and have provably correct statements and to some extent we get there we don't get there but the harsh reality is most of us don't have the time or freedom from our management to get to the point where we can do provable correctness for our code. And also the systems we run on and the environment we run on don't even allow for that even if

you wanted to. Right. But unit tests try to help us get there. They say, what are all the possible ways to kind of use this unit, this base of function, this minimally viable piece of code? And what are all the different ways to test it? And if I test all of those, then I should have provable, at least to some level, I should be able to prove that

it's correct, that people can call it and assume it's going to work. And that gets to an interesting point about, and we'll just gloss over this, about whether you should write the unit test before or after you write the code. Yeah, I've heard both ways. And I actually started writing the tests after because that's sort of more intuitive thing. And plus, you want to get the cool thing done, right? But I've found lately, I've been writing the test before. And this gets to something else that I think is really

interesting is when I just to finish the story, when I started, I thought tests were boring and kind of lame and no one really used them. But now I realize the cool thing about the test is that you could put your functions or your system under a state of distress that it will never see in the real world. Well, that it would be very difficult to replicate at a system test or an integration test. Yeah, and to be able to see that is really cool. So, for example you might write something that you know reads and writes records like the zombie DB for example I wrote that zombie database right and the cool part really was writing the tests where I had 128 threads concurrently trying to read and

write elements and then checks to make sure that the database wasn't corrupted right that was really cool and the first time I wrote it it completely failed the test I mean completely like the first record crashed the system right and then so I got it to the point where is more and more robust and it reached a level of robustness that in my entire web app and that Trivopedia nobody would have ever like I would never have the type of bandwidth that would have caused these issues to come up. But making something that was robust enough to handle these scenarios

was actually really interesting and fun. And so the writing test part was actually one of the funnest parts, even though it seems... I need tests for my grammar. I'm sorry, I'm sorry. It's one of the most fun parts, even though it's, you know,

canonically it's stereotyped as really boring and mundane. I'm sorry. I'm sorry. I know I did. You kind of write a test to make sure that the plus sign is plussing things. Or you check that something is null, but then later you also check that it's null, like that it hasn't somehow not been null again, because you feel like for sure that's happened to you once. And in reality, it was something else you had messed up. But you really keep checking and checking. So you can write an insane amount of lines of code trying to test the same thing. And so we talked a little bit about corner cases.

So, you know, kind of the method is you're supposed to test the different kinds of tests that are the corner cases of what you do. And if you test those, that should be sufficient. And that kind of interplays with another thing, which is code coverage, which is saying you should be able to execute every line of your unit when you write your unit tests. Because if you don't, you could be a sign of problems. One is how do you know that code that isn't tested is going to work? You don't have a test for it.

And the second thing is if there's no way to reach it, then it shouldn't be there. Yeah, exactly. And I've had this before, like through one way or another, it turns out there's an if statement that because of previous if statements and exception checking and handling and throwing, you can never reach that set of code. But you put it there because you weren't sure.

But now, like, going through the unit test makes you realize you can't construct a test case that ever exercises that. Then it should just be removed. Yeah, definitely. case that ever exercises that then it should just be removed yep yeah definitely another cool thing about unit tests is one of the strengths of unit tests is that they actually force you to write better code so for example one of the when I very first started really getting into writing unit tests I kind of sort of decided to just jump into the frying pan and unit test this code that I had just written. I was like I'm gonna do this and find out how this works. And I realized that my function didn't have any inputs or output. It

had one input which was just a file that it read data from. It had one output which was the name of the file that it output to. And I realized that it was impossible, and it was one function. And I realized it was impossible to test this function. I mean, it didn't even make sense because it was such a black box and it had been designed so poorly.

So the first thing I did was I took the function and broke it into pieces. And I said, okay, this piece, you know, inverts a matrix. And so I can invert. I don't have to invert a matrix from a file. I could just give it a list of numbers and tell it to invert that matrix. And this other piece does something different, et cetera. And it sort of got better.

But in the beginning, my very first unit test took, you know, 10, 20 minutes. And it actually wasn't even a unit test. It ended up being a system test, right? So take that example a little further, I think, because it gets into the other point. So writing testable code. So that's very important. It makes you write your code differently.

But then to go a step further, and we're going to talk about where mocking comes in. So Jason's saying he has a function which reads a file that the path has given to him, reads a matrix out of there, inverses the matrix, and writes it back out. We'll just say that's the code he wrote. So we wrote all of that in one function to start. Testing that is like near impossible. Yeah, exactly. So what he can do is say he's talking about breaking the inverting the matrix function out, but now he has code which takes in a file path, you know, reads the matrix,

calls, reads the matrix, that sounds awesome, reads the matrix, styles the operator, calls the inverse operation, gets the results, and then writes it out to a file. So that parent function there, the one that's still doing too much, but also, that's also really difficult to test. And you don't want the whole kind of one of the goals of unit testing is you don't want that test that tests that function to also be dependent on the test for the matrix inversion. Right. So instead of calling the matrix function by name, Jason could create a class which encapsulates the matrix inversion because then maybe he has different kinds of matrix

inversions depending on whether it's a very, very big matrix or a very small matrix or a Certainly shaped matrix or a sparse matrix. Yeah, so all those could be different matrices so now he has a class which represents that and Instead of having to go create a test instance of that which doesn't do anything meaningful You can use a mocking library when a mocking library is is a way, you can create mock objects on your own, which just, say, tests matrix inversion class, which doesn't do anything other than just return the matrix you got. Right.

And you can write that on your own. That's perfectly fine. But you may end up having to do that a lot. Yeah, you don't want to have to do this. For every class, you have some dummy class that does, like, nothing meaningful. Right. I mean, that could be such a waste of code.

So what a mocking library does, and they have these for many different languages but the kind of the root thing is always the same is allows you to create a tell it like i want this object but i want it to be fake right and then when it's called just return this yep and then once once you run your test code you check and say was it called in this way? And how many times was it called? And what was it called? You can kind of do all those checks. And then you check that it was called appropriately,

that it was called correctly, and you're not dependent on that. You're not dependent on the implementation of that class, just on the definition of the class, the interface of the class, which is all you want to be dependent on. Yeah, so getting to Patrick's point, let's say you just had a file that, let's say each line had a file that,

let's say each line was supposed to have a matrix on it. So you gave it an input file with three lines. The matrix inversion function should be called three times. And the mock, what it will do under the hood, it will actually have a counter for how many times the function was called. And it will tell you, hey, you actually, the very last line of your file was just an empty line, but you tried to process it as a matrix.

So your matrix inversion got called four times instead of three or something like that. It'll actually, the test will fail for that reason. But then the function still is not, to go this example a little farther, unless people think we're not doing justice, you still have this call down to the OS there, which says open the file. And that's still problematic, because you don't want to do that during a unit test. COLTON OGDEN.: Yeah, right.

DAN GALPIN.: And also, in general, as an engineer, you shouldn't be doing that. Because what happens if somebody wants to port that from one operating system to another? So then, now you see where this is going. Now instead of passing in a file string, you need an object which represents how to open the file so that you can abstract that away.

So you can kind of begin to see how you have object-oriented programming, unit testing, mocking. They kind of are swirling together here. And you can be poor at some of those, but if you really get involved in starting doing the whole process, it's going to make you better at all of them.

Yeah, definitely. That's definitely true. So I didn't think so. I thought unit testing was a waste, and then I started doing it, and I was bad at it in the beginning, and then I got better at it, and then I learned I really, you know,

you have these things you hear, like separation of concerns and testable code and, you know, all these things. And it really, like, it began like, ah, this is just people, like, you know, just wasting time and fuzzing. But in reality, like, once began, like, ah, this is people, like, you know, just wasting time and fuzzing. But in reality, like, once you learn to implement all those things, you learn why there are those design patterns and why things are important to be written in a certain way. And you build better code.

Yeah. And historically, I look at the projects that I've worked on, side projects that have succeeded and failed, and real work projects too. And I've noticed a trend that, especially with my side projects, they get to the point where they're not easily testable. Like whether I'm writing unit tests or even before when I just tested it by running it and seeing what happened, the point where they stopped becoming easily testable is right the point where I gave up. So for example, I made this hockey game and the hockey game came out pretty cool, but I had bugs such as, you know, at the end of the intermission in between quarters, it would sometimes crash. Or the statistics for many games, after you played 20 or 30 games,

the statistics were not being calculated right. Bugs that required you to play 20 games because I had no tests. Those things, when I started encountering those bugs, I kind of was paralyzed. I mean, there was a bug where after 20 minutes it crashed and I would literally play for 20 minutes, wait for it to crash and see if I could catch this bug. I did that a few times and then gave up, right? So a lot of these projects,

the testing is sort of what can keep you sane when you're going through it and kind of keep you motivated. And plus, it's pretty cool to write a test and to actually see some bit of code do something meaningful. Far before you might, yeah, but far before you might be done otherwise. Yeah, yeah, definitely. So it's a way to sort of give you motivation. Yeah, and that is a problem with a system test, right? So if you only do system testing your way to the end, there's so many potential problems. Like, you

spend tons of time debugging. Versus if you have unit tests, it kind of tells you where the likely culprit is if all your unit tests are still passing. And then that goes to another thing, is like, when you do find where the problem is, you know, because you might still have to kind of go through all your code looking for the problem, but you finally find your problem,

you should figure out why a unit test didn't fail. Yeah. And write a new unit test to make it fail. So we have this procedure where I work now where if somebody has an issue and it caused a problem, you can't say you're done until you wrote a unit test that makes that problem appear and show that as part of the fix, you have to make a unit test that failed before the fix,

you implement the fix, and then now the unit test passes. So to prevent somebody from getting into that in the future. And also, another good use of unit testing is it's kind of like documentation. So we all hate writing documentation and comments in our code. No matter what we say, we never write as many comments as we should.

And the nice thing about unit tests is it is a concrete example of how the function should work. So if somebody doesn't understand how something's supposed to work and you wrote good unit tests, they should be able to look at your unit tests and say, oh, he's testing it in this way. Well, why is it? Oh, because it does this.

Oh, I see now. And there's many times I worked on legacy code where it had, thankfully, reasonable unit tests. And I could go look at it and actually figure out what it was supposed to be doing

because the comments were terrible. Yeah, I saw one place where the code was, the comment said, you know, we want like tangent y over x, and the function returned y divided by x. And I couldn't get it. I went over to the person. He said, oh, yeah, because y and x are very small, and when they're small, the tangent function is equal to the line y equals x for small

values and it's like you know at least provide a unit test or some comments or something if you provide a unit test and your tangent function returns y divided by x and you have unit tests you'll be more inclined to think oh you know I should probably write a line a comment here because even to me calling the tangent function and getting the divisor you know the ratio doesn't make sense and so it's sort of as Patrick said it encourages you to feel like the the person on the outside calling the function if you think about this for people who work on open source or people are in a job environment so you're writing your code.

Then later on, you're going to read it. Maybe later on is an hour later, a day later, a year later, decade later. You're going to read it. That's one person. If you have anybody on your team or anybody on the Internet is looking at your project that's two people so at minimum twice as many people are going to read your code than write it you know so it took one it took you to write it but two times you are going to read it minimum probably more like 50 times or 100 times that code is going to be written for each time read for each time it was written and so just you so testing is sort of a way for you to just keep thinking about that

and putting yourselves in the shoes of the person using the code. So there are some weaknesses, and we can continue to talk about all this awesome, but some of the weaknesses is that it can get to management, it can seem time-consuming, and even it can get, I mean, even if you're doing a really good job,'re not overdoing the testing it still can take a lot of time to write unit tests and especially if you're not writing them as you go which is really bad you shouldn't do that and then you kind of get to the end I'm

almost done I just have to write unit tests yeah not good I have to admit I've done a couple of things I my current job where somebody said, unit tests? Question mark as a reply. So I'd send all this code out. I'd say, hey, take a look at this cool thing I made. And let me add it to the system. And someone would just reply, unit tests?

Turns out there's none. So yeah, all of us can be guilty of it. And it can feel like like like a big problem but but yeah just something that you start to live with another weakness is you can establish some constraints that might not be valid so as Patrick's was was suggesting to with the with his addition example right you might have some function that that does X let's say you have a function that let's see if some machine learning algorithm right and you

just you run your machine learning algorithm and you give it a bunch of data and it spits out 4.3 for a prediction so you write a unit test where you have this as an input and and you expect 4.3. That's a very specific number. I mean, if you make any change to your implementation, it'll probably change. It might become 4.2999, or it might become 5, and maybe that's okay, because the algorithm has changed in some way that's meaningful. So one thing that you have to be really careful about is writing the unit tests in such a way where they test the idea,

but in such a way where they aren't just very fragile and break because of things that don't really matter. And so this could be really difficult, and sometimes it's impossible. Hard coding numbers leads to this a lot. Yeah, yeah, definitely. So you have, like, you're using an enumeration provided by somebody else, and instead of going and trying to reference that enumeration, you put the number in. Yeah, you put two.

And then, yeah, then they change it and it all breaks. Yeah. The other thing is it related to kind of like establishing false constraints is just in general, you can get a false sense of what the code is supposed to do or how safe it is or how reliable it is because, oh, it's got unit tests. It's like, yeah, but even if the unit tests cover all the lines of code, even if they cover all the branches of the code, even if there's a lot of them, it doesn't mean they're testing the right thing or the meaningful thing or the crazy cases that could cause your system to fail. And then when it fails, like, oh, I don't understand what happened.

It's unit tested. It's like, well, you know. So you've got to be careful about those things because one bad thing about in the way, you know, there's different ways of doing it. So many people have where unit tests are supposed to be written by somebody different than the programmer. And the reason for that is that if you as a programmer write the unit test, you have the same assumptions in your code and the unit test. So, for instance, like this tangent function.

This guy says, oh, you know, it's fine to take the division, divide the two numbers, because for small numbers, that's OK. Well, what if it turns out, so he writes the unit test to reflect that. But then what if he doesn't have any test that the numbers are sufficiently small? And then somebody comes along and uses big numbers or reuses his function, right?

So because not just anybody wrote the unit test, he wrote it, he wrote it with the same assumptions. He only tested small numbers. Then that's a false sense, like that's a bad thing. Versus if somebody else just said, oh, hey, we have this tangent function and that's it. Write a test for it, right? He's going to write tests for all sorts of numbers

and then that's going to force the programmer to have check to say that this isn't too big of a number. And that makes everybody's life better. Yeah, yeah, definitely. That makes sense. So you can write unit tests all on your own, just like you can write mocks all on your own. You can do all this stuff without

any outside tools or help, but That would be painful, things are made better when you have tools to help you. And so we have a couple here. We're not going to talk about them all. Many, many, many programming languages have choices for what unit test you want to do,

for choices for mocking. Yeah, there's a bunch of them, so feel free to explore. Wikipedia has literally a gigantic table for each language. So Java, JUnit is the most common? Yeah, JUnit, that's the one I've used as well, and I think it's great. I think it's pretty cool. It has a lot of cool settings. If you use Maven, it works well with Maven.

It'll let you run tests in parallel, which is pretty fun if you're a multi-core machine and things like that. Then you can mock with Easy Mock, Mockito. I'm sure there's more. And those can have different strengths and weaknesses and there's different kind of whole different ways of mocking where some you tell it like it's going to call this, then this, then this, and then you call it like a replay and it's going to replay all the calls you gave it. And other ones you just say, here's what to do. And then you check in the end and say, did this happen?

Did this happen? Did this happen? So there's kind of different ways of even doing the mocking. C++? Yeah, C++ has CPP test, which is pretty cool. And on the mocking side, it has gmock, which is a pretty fun library. And C++ because of you know, it's kind of such a hacky language

anyways. The mocks are really hacky and they use all these crazy compiler definitions, things like that. But there's plenty of great tutorials. Mocking in general is kind of like one of those funny things where you use a lot of programming things you wouldn't normally. People in the mocking library.

You're trying to inject. You want to keep the class so that the person using the class doesn't know the difference. So you want to keep the signature of the class the same, but at the same time, you want to inject all this custom logic. And so yeah, that causes craziness to happen. But the good thing is these libraries do the craziness for

you, and they provide an API that's pretty simple. So if you do all the unit tests, one thing is these libraries do the craziness for you, and they provide an API that's pretty simple. So if you do all the unit tests, one thing is you can do code coverage. You know, that's a good thing. So what is code coverage? A lot of people don't know. Also, yeah, we mentioned it briefly, but code coverage is saying how many...

There's different forms of it, but the simplest is statement coverage. So how many of the lines of your code, think about it that way, are executed when you run the unit tests or whatever test? So line 5, 6, 7, 8, and 9 were all run. You had 100% because the lines before that and after that are comments and curly braces.

Great. But then if you have if statements, you'll have only 100% code coverage if the if statement is evaluated and if the inside is evaluated. The problem is there's this other thing called branch coverage which says like, oh, what happens if different branches are executed? So you could get like for instance, a null pointer exception if you have a bad least dated branching but you only have 100% statement coverage,

you wouldn't ever necessarily detect that that has a null pointer exception. Right. Versus if you have branch coverage, you could potentially catch that because branch coverage says every part of the branch has to be evaluated. Yeah, right.

So that's kind of code coverage and you need tools for that. Like, I mean, you could write your own, but it typically has to do some sort of instrumentation so that when the code is run, it is able to have things that run before and after the code

to know which lines are running. Yeah, exactly. Yeah. And so, yeah, don't do that yourself. Yeah, bad idea. But if you go to Java has a bunch. I actually, I haven't used any of the open source ones, so I can't really comment, but

I'm sure they're great because most of the stuff, I mean, you think about it, if you write a testing framework, you're already a pretty good programmer. I mean, if you got the moxie to say, hey, world, here's a testing framework, everyone should use it, then you probably know what you're doing. So there's definitely good code coverage tools for all the modern languages.

And then another thing it enables is, and this is a concept I think we've talked about before, but continuous integration. So continuous integration is that every time somebody submits a change into the repository, to whatever your source control is, the system, there's something that runs which rebuilds everything and runs all the tests. So every time there's a change.

So in many places, people just make changes all the time, willy-nilly, and then occasionally somebody kind of checks people just make changes all the time, willy-nilly, and then occasionally somebody kind of checks out a version of all the code, runs the test against it and see what has happened. And continuous integration says, no, no, no, no, that's a terrible idea. Let's have a, it's called like a build status.

Like, oh, currently tests are broken or the code won't compile. And then when somebody does something wrong, you can email them, you can notify them, you know when something's bad. Yep. And you're just doing this all the time. And when you have unit tests, it helps with that.

So if somebody makes a change to your code without updating the unit test or testing it, you know immediately if something's wrong or broken. Yeah. And again, don't write this yourself. There's, I think there's Jenkins and Java and there's a bunch of other ones, but they'll do all sorts of clever things. Like they'll run the, they'll do all sorts of clever things like they'll run the there They'll run all your tests daily

And then if if a test is broken they'll do a binary search Between today and yesterday to like to quickly find out exactly what change broke it So they're pretty awesome and take that's obviously more important for a much larger team I think unit testing can even be important if it's just you. Yeah, definitely. But continuous integration is something probably more suited to a more distributed and larger team. Yeah, yeah. It's probably overkill for a pet project.

But yeah, it's definitely good to have. So unit testing, we've got a lot of other kind of testing stuff. We'll probably have to do more testing episodes in the future. Yeah, we'll have to do a part two. I think programmers think it's, we we all assume is dry and boring but it can be very interesting and it's very important yeah and I think I mean as I was saying before the some of the like the stress tests that you write when you're unit testing cause you

to do things in a different way or learn things about the system that you wouldn't have otherwise known so I mean for example a really simple example was I had a system that basically did a bunch of math and it sort of tried to hone in on a certain number and when I wrote unit tests I found out that if I gave it a certain set of input I just the very first unit test just picked a bunch of random numbers and then tried to train it and then saw that the number it converged to that it actually converged so in other words given a bunch of inputs the output should start off crazy it should be you know negative 100 then 4,000 then negative 10,000 but it should eventually

settle down so it might settle on 3 million I don't know what the final answer is. But it will get to a point where every time you run that function, it would give you some number really close to 3 million or really close to some x. And I found out that for certain inputs, it would just oscillate wildly. And it would just give you crazy numbers. And it never settled. And it turns out that that algorithm, the fundamental math behind it, was broken broken and so I wouldn't have found that out without unit testing and so for that reason it can actually you know it could give you insight into something

that you just wouldn't have had otherwise if you had just you know ran it out on your on your on your input all right cool. Until next time. Yeah. Have fun writing unit tests. Woo-hoo! Let us know if you write unit tests first. And if you do, how that affects your, if that was a cool experience. Tell us how we're terrible testers and we got it all wrong. Yeah. We have the discussion section people have been posting.

So if you have any cool discussions. So we have a Google Plus community. That's right. The discussions in the G Plus community. Or you can comment on our Plus page. We have the Plus page as well. So there's many ways to contact us. No excuse. There's the blog,

the Plus page, there's the community. Also, and you can email us. That's right. You can email Programming Throwdown at gmail.com. And those are all great ways to reach us. And let us know how these things turned out. Alright. Thanks for listening. See you later. The intro music is Axo by Binar Pilot.

Programming Throwdown is distributed under a Creative Commons Attribution Share Alike 2.0 license. You're free to share, copy, distribute, transmit the work, to remix, adapt the work. But you must provide attribution to Patrick and I and share alike in kind.