 So last year I created this presentation for this conference, and I actually did it, excuse me, did the talk about four times, and actually I got lots of flak, I got lots of love, so I decided to start 2009 off and do it again. And this year I want to do little things a little bit differently. This year I don't want to talk about testing, I want to teach testing to you guys. So everybody here, who works in corporate America? So you guys have meetings, and when you go to your meetings you have an objective, and I'm going to give you an objective here today. And our objective is, if my, oh I got to turn my mouse on, alright, and my objective is, is to get, there we go. I want to teach you guys one new thing, and I don't care what you get out of this, but I promise you by the end of this talk, in the next 40 minutes or so, that you will learn one new thing out of this. So, let's get on to the talk. So today we're going to talk about, no, we're going to listen to this great song first, that's what we're going to do. The song this is. Nah, nah, I'm kidding. Now today we're going to the first time, and just to let you guys know, it's Taft, like Kraft, the T is silent. You know, because people have asked me this, and I had to come to conclusion, and it is, it's Taft. So, first of all, let's talk about this. Let's talk about this. Taft is a phenomenon, not a literal thing. Now what do I mean by this? People always come to me and say, Brian, are you testing right now? I'm like, no, I'm talking to you. And they'll come up and say, Brian, are you testing right now to test this code? Someone, I have people who go into my GitHub account, look through all my projects and see if there's enough tests. No, you guys are dumb. Don't do that. It is a literal thing. We're talking about testing when you're supposed to be testing and testing things that are supposed to be tested, not everything. You know, I'm taking a step over here. I don't need to test that. I'm just going to do it. That's silly. So, for all those people, I want to send a PSA out. And you guys know what a PSA is, public service announcement. And the first one I want to send out to is, with this video, I love videos. Have you guys seen this video? Has Rails jumped a shark? Classic TV show right here. Other things that have jumped a shark this year. And the first thing is, this thing I like to call CATFT. I guess we can call it CAFT. And that's people who complain all the fucking time. You know what? Take it that way. I want nothing to do with you guys anymore. And here's another one. And a lot of people in this room might be familiar with this people. And actually, let me say this one really slowly. Being an internet loser who hangs out on Ruby on Rails all day just so I can feel some kind of power all the fucking time. You know what? I jumped a shark. And you know something? There's this website out there called Rails WTF. That jumped a shark. They really do estog me. All my blog posts, all my Twitter posts end up on this site for some reason. These guys really do love me. So to you guys, I'm up here and you guys aren't. So whatever. I'm complaining. Let's talk about theory. And that's my littlest one. That's Abigail. She's going to help me do this thing today. And the first thing we're going to talk about is our testing toolbox. Because a lot of people ask, well, how do I test? It's not about how you test all the time. Sometimes you just need, you need some tools. And I'm going to go over seven tools actually to help you test. And let's start off. First you need some magnets and some rubber bands. The rubber bands are because, you know, they don't fit you. And this might sound kind of silly, but to start somewhere, you have to start at the beginning. And first thing you're going to need is something to test with. The second thing you're going to need is something to think everything else out. Just think about this for a second. You're going to get what I'm talking about. The next thing you're going to need is something to keep metrics. Testing is more about you can test, but you also need to have some kind of standard to compare your previous tests to. So I like to keep metrics all the time. And I'm not creating an acronym for that. And something to keep me grounded with reality. I'll explain this one. And another thing is something to keep me testing. And another thing is also, I am really sad this is not working, but something to create testable data. And Jim Wyrick talked about this yesterday and his fixtures and that long C word, but I can't say, so I'm not going to say it. And also something to keep me automated. I'm a huge automation fan. I really am ex-unix, ex-security, ex-lazy person. So I'm always looking for ways to automate everything I do. So let's go over these seven items. First, we want to talk about something to talk with. So the first thing I want to do is on the flashback of 2008 when we were at the Holiday Inn down in Orlando. And what I did is we're flashing back. I put up this slide and the first thing I said is, Brian L should like RSpec. And you know what? I did like RSpec until I met Shuda. And I also do this slide and I called this my magic testing combo. To tell you the truth, it doesn't look much like this because I use Shuda and RSpec. I still use test unit and RSpec story runner has been replaced by something else. We'll talk about later. But after using a lot of projects, there's a big split. And I realize that, you know what? It doesn't matter which one you're using. They're both robust enough that you can use either one. Just pick this one you like. So they're kind of even. I can't really say one is better than the other because either one has faults that make it, it makes it a moot point. So use what you like. And you know what? I mean, evangelize it. I like to hear the competitions, but use something. One of the losers here are the people who aren't testing, who don't know this one or this one. So let's get into our testing ones, the least ones I use. I use RSpec. And I like RSpec because RSpec reads in a nice English way. So I could say, if I have an apple, my apple should taste good. But Shuda gives us these things called macros. And we would write these a little bit different. And it should have speak. This would be like apple should taste good. And of course there's good old test unit, which we all love. Hey, Nathaniel. So we're going to all school assertions. I don't want to read this to you guys. You guys can. And then there's something new. Jeremy McEnally from ENCP down in Huntsville comes up with Context with Matchy. And the reason I didn't put a demo slide there because it can look just like RSpec. Or it can look just like Shuda. It's a good idea. This guy needs to keep on hacking because I think he brings out good ideas from everybody. So look at this GitHub slash Jeremy McEnally. He has a couple cool projects there. So the next thing I said we needed is something to fake everything else out. And you guys have any idea what I'm talking about here? Anybody? There you go, Anthony. So yeah. And the first one, and this is the one I use the most. I use Mocha. And the only reason I use Mocha is because it's what I'm used to using. I have no good reason to use it. But you know, it's what I've been using and it's what I make my developers use. So I try to stay consistent. And this is just an example of stubbing and mocking with Mocha. And the next example I'm going to show you is FlexMock. And the cool thing is that the FlexMock author is here. And I hope that my slide is correct, Jim. Because if it's not, just chalk it up as it's awesome to put on the board. Okay, thank you. But here's something else I've come up with. And I've heard people talk about this lately. And actually ENTP posted an article yesterday on their blog about RR, which is this double thing, which is actually kind of cool. I'm going to look at it. And I advise everybody here to take a good look at this. The method they're doing is actually making it a little bit more obvious when you have a stub and when you have a mock. So I can just have my stub and just say return this block. So taste, return whatever is in this block, which is good. Or my color, turn red. I love this. I will be using this in a project very soon. So you'll probably hear about this on my blog. And then we have the good old standby RSpec mocks and stubs. Nothing to talk about here. I'm sure everybody has seen this. So the next thing I'll talk about is metrics. And who here keeps metrics with their code? Who's here really is anal enough besides Jehuda to really look at your code and look at the metrics of your code. The first thing I do is Ryan Davis, good old Zen Spider, create something called Flock. And Flock, basically you know what a Flock is. He flogs his code and tries to do pain to his code. And what it does is it gives you this number and I'm actually going to show you a run of it. And on my blog earlier this year, actually last year, I came up with this chart of Flock output numbers. So what we have here is 0 to 10. If your method ranks 0 to 10, you're writing good code. And I don't even write code like this. I'm not really that good of a coder anyways, but I don't write code like this. Nobody in my team writes code like this. If you can do this, it's awesome. Most of us fit right here. We're not bad. We're doing, we're writing OK code. What this does, it measures method length, branching, conditionals, and assignments. So just make sure that your code is easy to read. It's actually a pretty good indicator of how easy to read your code is. So then we get into where, you know, our little bit naughty developers get. You know, they might write some code, might need some TLC. And then we have this write it over. And then the next one we have is where you should never be. And you'll see this right here. If you're running FLOG and you see this in your code, think of me. Say, Brian said, what the fuck are you doing? Don't do that. So I can't go without having a demo. And I don't do live demos. So I hired a team of midgets that are behind the board and they're doing it for me. And notice I'm NVM, no text mate. And I'm NVM. And I just ran the FLOG on that code that you saw. And notice that those are my FLOG scores, the 21 and the 17. Notice that I'm not too bad, no low numbers there. But if you run this all the time and actually just run it again, if you run this all the time in your code, what it will force you to do is first write smaller, easier to read methods, not use so many branches, and, you know, keep your code in check. And actually there's a tool that I'll talk about later that, and this is where I got most of the stuff from, there's also Securo. Does anybody use this? This is kind of weird. This is kind of out there. And I can't explain to you what psychomatic complexity is, but I know that once I run this on my code, it becomes less psychomatically complex. And it's all about metrics. Who cares what your metric is? I'm less than I was before. Go read this site. I can't explain this to you guys. I had to go look up psychomatic in the dictionary and I still can't tell you what it means. The next tool is Rik. And that's my daughter helping us explain what Rik is because they didn't have a good picture on her website. Rik helps you find code smells. And, you know, I'm usually good at finding this in my code reviews from my developers. I just look at their code and be like, that sucks. Do it over. But this is actually something that we can measure. And once again, I have my midgets, and I mean my short people behind the board running my Vems. And what it does, this is kind of cool, it actually runs on your code and it gives you pointers of what you can do to fix your code. And you might not do it or you might do it. I love things that tell me how to do my job a little bit better. And you say, well, how does this help you test? What you do is you read green refactor. I think it's part of your refactor. You should be doing things like this. So if you need some help with that refactor phase, here you go. This will help. So the next tool is good old R-Cup. Mauricio, I don't know his last name, Fernandez, eigenclass.com, created this tool R-Cup. If anybody looked at the code of R-Cup and actually tried to figure out how to make it better, the guy's a smart guy. Or he's completely insane on one of those because he has some really hard to read code. Or maybe it's just because it's so crazy what it does. But what R-Cup does, as we know, is it tells us when we run a test of what code has been run or what has not been run. And it's only using C2 code coverage so it actually can't look in your, if you have an if with a boolean in it, it can't look at both sides. It doesn't want to look at one side. It only cares about what lines have run. But you should have this. As a matter of fact, before you're checking your code, you should always make sure that, hey, my code coverage going up or my code coverage going down. Right? Wow. I'm going to, I'm going to, I know you are Lark. I'm going to come back here next year and I'm going to ask that question again. That's really, at the minimum, this is so easy to run in your code. All you do is type R-Cup with your directory or your file name and it spits out something close to this. So another tool that I found is called Rudy. And this is an interesting one. Rudy is more about object-oriented design. I guess that's why it's called R-O-O-D. I don't know what the I stands for. And that's my daughter again. What she's doing, she's peering in my code looking for the bad stuff. Am I doing good OO? And actually I have a demo of this too. So I'm back in my VIM and my little people, that's what they're really called, little people. And this actually goes back pretty quickly and what it does is kind of like, reek, it just tells you things that you should be doing through your code. And that's what it does without elf clauses. Yehuda had that this morning and I wanted to call him on it. You've got to have an else clause in your case statements. So I didn't know that until I was putting this code. So next thing I want you guys to do, I want to have like a little call and response here and I'm going to say this and I want you guys to say it back because I think this is so important to measure and analyze my code is to know my code. That was awesome. That's exactly what I'm talking about right now. So the next, let's move on. So now we're talking about keeping ourselves grounded with reality. Anybody have any idea what I'm talking about? Any guesses about what I'm going to say right now? All right, I'll give you a little hint. Grounded with reality, grounded with business, the people who pay our bills, the acceptance of our code. And in the Ruby land, there's only I guess really one major player that's actually approachable when it's Cucumber. And what this is, this is Aslak Halasoi from the RSpec team put together this great piece of software. I guess it was a clean implementation of the RSpec story runner using TreeTop as the parser. And we use this. I try to get my guys to use it all the time. This is great. And a lot of projects are actually moving towards this. So what do we have here? What Cucumber gives us is plain English high level acceptance test of our code. Everybody in this room, including my wife who's back there, can read this. And they can actually see what this acceptance test does or what it should do. And the cool thing about this is that not only do your developers have insight to your code, your business side methodology you're using to develop, that person has insight to your code. They can actually help you write this kind of stuff. And you're saying, was this testing? Yeah, it's testing. It's acceptance level testing. It's actually very important. So go on again. I got to show a demo. So inside of the inside of I do have a demo here. It's taking a little while to get on there. So I have a Rails project called Downloader that we're releasing and it actually just lets you download files from the Internet. But we have features for it. And notice that I know it went by pretty quickly, but what we have here is that was behind the scenes. Ignore that guy. What we have here are plain text descriptions of what my code should do. And you say, well, how is this different than my low level test? Business wants your low level, your functional, your functional, maybe some of your integration test and your unit test describe what your code what you think your code does. And what they should do is they really should meet the medal. And I actually explain it like this to people. So moving on, now what we need is something to keep us testing. And who here is using continuous integration all the time? I mean this is part of your workflow. I know hashrock guys, you guys. It's like your way of life. At first, everybody, and I actually was on this bandwagon for a long time, was cruisecontrol.rb came from ThoughtWorks and it's an awesome piece of free code. Only problem with it is it's hard to use. It can be configured because it gives you all the source, but it really gives you a lot more than what you really want. So these days I'm actually telling some people to use this next project called integrity. And the difference between cruisecontrol.rb and integrity is first that cruisecontrol is a Rails app, integrity is a Sinatra app, is that the approach to testing is much simpler. All integrity once and I don't have a screen to show you this is, all integrity once is what do you want me to run? And it only works so it makes a lot of assumptions there and it has all these notifiers that you can use it. We're using with the campfire notifier that Chris Wonstraf wrote and I made work a little better. So if you guys are going to try this and you want a free option, integrity is easy to use. Don't use it on like Red Hat Enterprise 5 or CentOS, it won't work out the box. Do it like on Ubuntu and it works very well. And if anybody has any questions about it email me, come by me I'll help you with this. And if you're in the JRuby land I think this is called Celerity it's a very good tool for testing your JRuby apps and one thing that the Celerity can do is it can also do, it can do end testing, actually test your JavaScript and which is a big deal because most of our projects in here we have all these code and we have all RubyCodes tested but we don't have the actual user click tier and this part works. If you have a JRuby app you can actually have Celerity run it and it will do the form testing but some enterprising individual on GitHub has figured out a way to make this run with your MRI apps. So everybody else's apps. I have not, I have tried to run this there's a couple of issues, he could use a few patches, it only runs on port 80 right now and some other things but this right here is the feature this is definitely, I think if he if he doesn't make big noise about it I will be making big noise about this very soon and that's why I put the link up here just remember I guess the Langlex part so Jim talked about this yesterday fixtures, fixtures, fixtures something to create testable data I guess this pattern is called the object mother pattern some people refer to it as the object mother pattern only one thing to say is don't use fixtures don't use fixtures just don't use fixtures I can find one really acceptable test case for using fixtures and this is what it is if you are testing uploads in your application use a fixture for that put it in your fixtures folder in your Rails app, go test fixtures files and then put your file in there but for everything else there's other things we can use and let's talk about this first one is factory girl factory girl is written by Thoughtbot these guys have pushed out a lot of cool code Shada this, they have something called clearance they have a couple other projects that are really interesting and one thing I like about factory girl is that it's really unobtrusive to everything and I promise I would show some code and what this does is it doesn't invade your objects it actually uses the factory pattern to create your code here or to create your objects and actually this is for something I'm writing so this makes no sense to you guys I haven't released it yet I'm not constantly releasing and actually there's another project that I was informed of called machinist and machinist is something similar but machinist is really intrusive that it includes itself into your classes and then generates and it can generate fake data for you using it, sham, sim, blah blah blah blah blah I like machinist but I like factory girl so I have a problem now so what am I going to do? I've actually approached both of these teams and I said, well, why don't you guys merge products and you know what, we can make a franchise product and I said, you know what this is how I'm going to help I'm going to help you guys name your new product so I've been tossing around some ideas I have machinist it's both of them, it's the spirit of both of them and then there's another one a factory girl that rolls off the tongue then I was like, you know what, we are we're in the Y generation or the speed generation now we don't use big words I can do better they're not expecting that from me I'm just going to name it this cuff so this is where I am right now maybe there will be a cuff one of these days maybe there won't but either way, machinist and factory girl are very very good for generating data and actually I don't have a slide for this because I want to keep this quick but the radiant project actually has something else coming out or I don't know it's called data sets and this is a very cool idea I didn't put a slide up for it but if you go to github slash aiwilliams slash data sets they have a very good solution for generating a large amount of data like if you're testing radiant pages in your CMS actually probably in the next version of the screencast the next version of this talk I will have a slide in there for that because they definitely deserve their props and you know there's also scenarios which I do like but I've moved on to these two so there are options, just don't use fixtures because fixtures cause problems and jem's talk yesterday explained that in great detail the problems with fixtures so next we need something to keep us automated and we always need to remain automated it's very important because if you have to run your tests all the time by yourself you're probably not going to run them as often as you should be so what do we use we use auto test and you know it comes in zen test and this is another Ryan Davis tool I kind of wish he would just pull auto test out and use that instead of having to download and install the whole entire other zen test who else uses any of the other parts in zen test who else knows what the other parts of zen test are because auto test is like 5 files and there's a whole bunch of other stuff in there don't look at it but so on my friends are back and they're going to show us about auto test so to give you a little history here I work for a company called sourcefire we have an open source product called snort and we have a whole bunch of open source rules that we use for you know for bad sub detection on the network so we're basically creating an API so people can query this from the internet and of course it needs to be tested so this is how I do it I actually go in there and I just run auto test and it runs so whenever I change my code whenever I change my code it always runs my test for me I don't have to worry about what tests I need to run because guess what it's always running a test it knows a file I changed and it knows what tests have not passed so it only runs those because look how many tests are in here it only takes a couple seconds because I believe in fast test but still and I ignore those deprecations that's bad developer, bad developer, bad developer but um but notice we do, we're very good we actually try to stay below like um I say like a 15 seconds from a full run for my quick test set if anything put about that nobody's going to run it and I've been in situations where I actually was the guy at the back row where um I don't know how long that test we took the run because I don't think it ever did run while we were there so we don't want to be in that situation it's the whole broken windows thing keep them quick, keep them fast, keep them green and you'll always run them so moving on this is what we're here about and that right there where my seven my seven tools for allowing you to test all the fucking time and that is the foundation of what I think you need to even get started with testing so now that we have some tools for our toolbox um now we need more theory so now we have we have little Abigail we have our big sister Jaila and they're going to help us with this part so now we need some strategies and the first strategy I'm going to talk about is um spiking and throwing it away say if I hear spike and throw it away or if you guys are really a fan of throwing it away my developers have a problem with this and guys who work for me I'll say I don't want to solve this problem why don't we just sit down and we'll hack out code for half an hour and when we're done we'll understand the problem and then we'll throw it away we'll delete it and they'll say to me well it's not a waste, I said well no it's not a waste what I learned from there is the solution and now I can go back and write tests with my solution and then implement my solution I don't want to have that bad code in my system because it hasn't been tested it's like that spike all it allowed me to do was get my thought pattern right and that's all it was doing so I'm serious throw your code away seriously and I know there's a lot of I think there's a lot of believers in here but a lot of people watching this video where's the camera which camera is this camera these guys these guys I'm serious so keep it keep it short 30 minutes if you're spiking longer than 30 minutes for coding you're in a code session kill that and this is another slide I don't have a slide for this but I only code in 50 minute sprints I don't know how people can code all day long I code for 50 minutes I get up I go to the bathroom I get a drink for like 10 so I figure and I do this all day long I don't understand how people can sit down for 10 hours straight but I think you will be so much more productive as a coder if you get up once an hour and move around it's good for all of us all right back to our talk so now we have this another second point and this is something that somebody called me out on and I'm going to defend it right here right now today stop what you're doing look at your code and write tests if you don't have enough tests for what you've written go back and write them and then you'll want you to delete those tests are you telling people to delete your tests? yeah I'm telling you to delete your tests and you know why I'm telling you to delete your tests? do you know why? because I'll tell you why people can search for me on github I can search for a lot of people on github and what I see in a lot of products or a lot of projects are really bad tests a lot of assertions of 5 equals 6 or a lot of things that would happen anyways like low level tests where we're testing assertions or testing branches or second conditionals we don't test for that we never test for that what we always should be testing for is the behavior of our code don't test about what it does test about how it should perform and not perform for performance reasons but how it should act so test the behavior so that's what I was saying there and you know what Greg Paul had caught me and I didn't get to preface it with what I was really saying there because you know I was in the moment that's what I'm saying now I want you to go back and look at your test and if they're bad tests delete them you know why it's only code write it again because I bet when you write them this time it'll be a lot better than it was last time and I also like the little octo-kitty thing I just want to have a slide of that github guys has been great for our community we should give them a round of applause basically we're testing all the time sometimes we delete our code we're testing test driven development who here is a heavy TDDer BDDer about TDD with auto-test something a little bit different something that I didn't learn in school so I want to talk about it right now this is a method and this might not be the best method but a method for actually TDDing with auto-test it seems like it should be like plainly obvious to most people but some people still have issues with this so I want to talk about it it's red, make it test pass, it's green and then your refactor actually for the green it's right the least amount of code to make it pass and now that's cool but I want to talk about it you guys saw this movie didn't you alright so I'm going to talk about the message I don't have a name for this method but I'm going to call it the message so let's say we have some code here let's say we want to implement an object called a square and we want to test for the area should be a length of the side square so with the area so if you have one that's a square that the side length is 4 the area should be 16 am I right I don't have a degree so am I right alright think I'm right so I wrote this test and of course you have no implementation of this so when you write your test it's going to be like hey wrong among the arguments and I did cheat a little bit I actually did create the square class and that's all it's an empty square class and what I want to hear is it's called the message method and the first thing you need to do is you need to look at your message and that's the message and what you need to do is make that message go away so what is our method for doing this we either we have to change the message or we make it pass and that's what I tell people now change your message or make it pass so since you're using auto test whenever you change your code it's going to run anyways so how do we do this the first thing we're going to do is um we put our initial I'm sorry did I miss a slide there we go so we're changing the message here and what the message was before was we had a wrong number of arguments for initialize it's because we didn't have an initialize so now we have an initialize with sideline notice there's nothing inside of there it doesn't do anything but all I was doing was changing the message it says undefined method area for my square instance so and you notice and I'm pointing out the message for the people at home so they know what the message is and what I did now is I put in a method called area not supposed to do anything this message should not do any I mean the area method shouldn't do anything you really have to take these baby steps like this it's a very important part of the process so what do you do right here you change the message or you make it pass so now when we're in an area it's always going to turn nil because the method doesn't do anything so now what I'm going to do is I'm going to change the method and I'm going to make it pass so of course now I had to write a little bit more code here and this might not be the best implementation but it is an implementation because I hasn't been refactored yet but now I've made it pass and now I'm at great which is where we want to be but I was being and Yehuda you were right the real answer for this is I should have put 16 right here I'm up here on the stage and I didn't want to have like 15 iterations of this so what I'm just going to say this is slide 94 let's say I had like slide 94 sub 26 this is what it would look like I'm actually caring about your time so now we're back to all our test pass so what do we do when all our test pass is that going to run again I'm sorry so what do we take from this don't be afraid to throw a test I don't be afraid to throw a test actually Yehuda gave a great test at RubyConf about this and that was one of the lessons learned we want to move we want to move from less from more unit tests to less unit tests we don't really want the unit level I mean it helps us get to where we need to be but when we have these great APIs and we have tests at our API level who cares what the metal stuff does as long as our API is correct so don't be afraid to throw a test away and also because we just need to move on my daughter knows how to do it so we need to move on too and I just put this line in here because I thought it was cool once you start you can't stop and that's how I feel about the whole testing and getting into throwing things away and making everything right you can't be scared of just tearing it all out and saying screw it let's move on so now let's talk about a little bit more theory and this is not the testing part there's nothing to do with testing this is the hash tracker break pair program if you can you will write better tests if you have a buddy there with you writing tests with you I pretty much guarantee it you will write better tests if you don't cheat and what I did in my little slide back in slide 96 is I cheated don't cheat go through all the motions don't cheat your code don't cheat your test because all you're doing is cheating whenever you have to look at it next time or you're cheating next developer cheat the bottom line which means you're just fake so don't do that so now we're out of theory and I put this picture up here because someone put it on Facebook the other day and I just thought it was cool anybody know where I am in this picture? actually I was the funny looking kid on the bottom left and I think that's the reason I spend so much time playing these things like this keep me grounded keep yourself aware of it this is fun we're here on a weekend talking about Ruby code so now I want to talk about some more real stuff people ask me this what does your desktop look like I don't subscribe to the hash rocket 30 inch monitor thing and I don't get the program pair program a lot unfortunately because I'm like management real guy and usually just ends up over here somewhere so I actually just used this Mac I use this Mac for everything so 1440x900 is my resolution I figured out I use them I have a terminal and I have auto test and this is how it looks I actually almost have an Apple script it actually does all this for me I think this is very important and I use black I use light text on the black background I just think it's easier to see some people might not agree but if you notice right here I actually split and this is why I don't use TextMate anymore I want to be able to see my test code while I'm writing the implementation I think that is not too much to ask for I love TextMate and I actually did use it for some of these examples because copying as RTF is great for TextMate but when I'm actually trying to get work done them or Emacs I've been much better to me in the past weeks and actually if I read my blog I actually do this experiment and I'm going to finish it up with a post on why I'm sticking with them so let's look closer at my work area here so I use NerdTree NerdTree is awesome NerdTree them plugin and right here you'll see my test and you'll see my implementation down here ignore this very long method it actually didn't flow very well but you know what? we always need something to improve one but it does work because it's tested and then we have our test window which you guys have seen, we run on my test I don't run my features all the time because sometimes you just don't want to run your whole test week the whole time so most time I just turn I just have auto feature equals false so I don't have to run that one thing you need to realize is I think one of the pro tips here is that the faster you know that you failed is the faster you'll know your success so instant feedback is always the key and so now let's get into my talk my talk is like eight slides long that before was like the preface now let's talk about the talk so what do we need to do to be better at testing all the first thing we need to do is we need to write test first you can't get around that write your test first when DHH yesterday said that he doesn't write test all the time he was wrong because that app that he said he was going to be using is like there's a new status app and it needs to be tested write your test first I don't care if you're writing five lines figure out the appropriate amount of tests just say if you're writing a if you're writing a Sinatra application and it has one action just put a test in there that says that if I pass this in there a success if I pass in there it's a 404 big deal or it's a 500 but you need to have that test because you might have been in that right state of mind then but how do you how do you judge if features change somewhere else in your app or if you had something else on you might as well just start at the beginning write your test first only write code to make your test pass if you're putting code in your app and there's no test behind it or no high level functional or integration level test if you're writing a Sinatra application create a reason for yourself to write code and the way you do that is by writing a test submit code to continuous integration and that's my little continuous integration right here she's handling my code you know what's going to happen is you're going to write code and it's going to be awesome on your desktop and it's going to be super awesome on your desktop and it's not going to run in production if you submit it to a continuous integration on another server you at least have some guarantee that it's going to run somewhere else and it wasn't because of the esoteric settings that you have on your box number four is write more tests you're not writing enough tests right now so think about it, write some more after you write those tests write more code and number six is refactor constantly that's all what we do and a lot of people won't say this it's a craft, it's not for four to eight years or 12 years or forever like some of us and learn how to become programmers the people who are here the people who are like leading what we're doing they treat it like a craft, they don't treat it like it's one plus one equals two they sit down like an artist and maybe it isn't art but they sit down like an artist and they always should improve their craft so what we're going to do is refactor constantly like I did in these pictures we did for Christmas if you notice we did it until we gave up so what happens if you do if you follow my six rules you'll have profit, at least internal profit I can't speak for you you're making money so let's go on to my next part I talked about gathering metrics and those methods that I gave before, Rudy, Riek, Arkov and the other one are easily done for you by Metric Food Metric Food works with Food Project no matter what it is use this this is probably one of the most important things I can tell you to put in your app right now put that in there and another important thing I can tell you is read more source code everybody here should read like a novel go find a project actually I've learned a lot lately by reading Riek source code, believe it or not I've read it and I appreciate some things a little bit more because I think there's a lot of us to learn from just methods I've learned a lot from Yehuda posting his explorations into merging Mervin and what is that? Rails damn guys so read source code I think it's one of the best things we can do for ourselves and I wanted to set this up for questions and I know I'm like 40 minutes in so my next few slides are bonuses you can use OSX these might be relevant if not I'm sorry I can't help you one of my things that I want to tell people is don't use your mouse and this is nothing to do with testing I'm done with that talk don't use your mouse get the Google thing or get Quicksilver or get Launchbar I'm actually representing I'm actually saying Launchbar is a cost but Launchbar 5 is way better than Quicksilver ever was I'm not using getX I don't care if you're a get master I mean I can do a lot of the weird things from the command line but you will not have a better commit or a better view of your project if you're not using getX on the Mac and I think this is one of those projects like TextMate that make people who aren't on the Mac think about maybe I'll be more productive on the Mac I am all about them today because I had this couple months long and I've decided on them it's funny back in 94 when I got my first paid Unix job we used something called Vi and I always spent a whole bunch of time trying to get away from Vi and now I'm looking back where I am so so now and this is something that I don't think people use Vimperator if you guys are using Firefox and you like Vi now it actually allows you to do mouseless things with your editor just search for it it's actually pretty awesome and I don't have anything for it but it's pretty awesome so all I want to do is leave you with this all we can do is make our code work like it should and what it should is up to you really and the only way we can do this is by testing on fucking time so I have a couple things coming up and the first thing I do is I have TAF TV and I've been wanting to do this I've been wanting to do a screencast series where I talk about just random things no cost I actually do have some episodes planned where I will actually dive into more of the topics that I talked about today in a little bit more detail they won't be crazy like the Rails MB guys those guys, I don't have a green screen so I can't do all that but I promise you and so March next month we'll have test all the fucking time TV and I wanted to let you know that my wardrobe and travel were sponsored by my employer Sourcefire and they allowed me to get here today and I want to say thank you you guys have been great so now I know I glossed over a lot of things but I wanted to get a lot of things out there so I know there's questions and I want to know what happened in IRC what's up? you have to tap this dot com to resolve have you registered that? it does resolve, the MX resolves there's a story, I'm going to give a quick story last August I did a talk in DC about I did a talk in DC about testing and some shlub registered at tap.com and I had to go back and forth for a little while and I got the domain back and I was just so happy I had a set of email and I didn't put up a website so that's what happened with that there will be one there and it probably should forward to something else thank you for pointing that out in public alright anyone else? yes how do you keep your tests running as fast as possible? make sure this is more of a let me explain this to you I'll give you a little if you have read the pragmatic thinking in this book they talk about the triphus theory or method and there's like five stages or four stages that go from beginner to expert and what I'm trying to say here is there's the beginning answer and then there's the expert who knows and it's more like a sense of I just know what I should be doing I can't give you a definitive answer on that what I can say is stay out the file system never touch a network respect your object boundaries so if you're passing if you're testing object square and it needs something from object line mock that out who cares you don't care you just pass that in so yeah those are the three things I can tell you do you directly relate a vlog score to test me? no I don't think it goes down to that level you can't because flog only goes to your lines it wouldn't actually not know that and flog doesn't look at times either but that's interesting though anybody else? alright oh Mark can you compare contrast shoulda to r-spec and solvus from fighting about it all the time? yes I can I can start I can give you something on high level shoulda is a set of macros on top of test unit r-spec is its own thing that can actually run test unit um that's the easy answer the other answer is shoulda is um is macro-based and it introduces things like context and little should blocks r-spec the big I guess the big things for that are the syntax of your assertions I think r-spec really what it really wants to do is get you away from the old x-unit style assertions so instead of saying assert equals foo to thumb it would actually do foo should equal thumb so r-spec macros no reverse that shoulda macros r-spec matchers yeah that doesn't make any sense to me either yeah just recently now all of the shoulda macros can run in r-spec so I was mainly wondering how low level what kind of troubles you have oh okay I'll take my problems with r-spec and this is why last year I decided I would not use r-spec pretty much from day to day if you ever have to r-debug an r-spec you'll shoot yourself in the leg because you'll be like how did it even get there and where did this ad-exit come from when am I doing a test unit I thought I was with r-spec with test unit or anything built on top of that there's a pretty clean path through the code so you'll know before you died while you're there so if you happen to find a bug inside a test unit you'll find that bug pretty quickly and that was my problem with r-spec and also a test unit is a little bit faster in r-spec I mean I know it was a little while ago I don't know how it is now but on the high level day to day stuff they're okay they're even when it's fine yes I just want to say about spiking I find that sometimes I'm not talking about like hours but if you have to go to like half an hour it's useful at the beginning to write a new high level test so I know normally in spikes people don't write tests at all and it's actually useful to not but sometimes you're like okay I know basically what it has to do you can write some high level tests and then you can program and make sure you're not breaking stuff all the time or when you get to like okay time works now I think you've evolved to a level where you actually can realize what's wrong versus what's right and you have a sense of feeling well this feels right versus this feels wrong but a lot of people aren't even to that level yet where they can't say that they have no feeling their feet aren't even wet for testing they have no idea where they are and this is what I'm trying to do is get people close to your level where they can actually make that decision that you know what I'm going to write some tests now then I'm going to spike like that that's just going to be how I develop and actually that's pretty close to how I develop all the time I always start with I call them my little exploratory tests so high that they won't really do anything and they probably get deleted anyways but at least they get me started and the point that I really do use this for if you're ever developing a command line application testing a command line application I should write a blog post on this it's a hard thing to do because you're like oh that's he no it's not that's how I do that next question one of the things you said about the testing was you test the behavior of the application like with RSpec where it has given whatever and line then log and Lord had those exact kind of things in his talk yesterday we're talking about the acceptance test and knowing how far to go with the testing is always how much do I actually need to test right it's always kind of a controversial topic so past the acceptance criteria as defined by say a customer thinking you can get them to get as specific as you have there where they're testing the behavior like how far past that would you go with the testing since you were saying like you don't necessarily need to test conditionals and certain things like that well it goes back to that how comfortable are you it's a certain level at the beginner level maybe at the I don't know if it's the journeyman level the second level you might have to go a little bit further into your test being an experienced developer you might say well I already know what's going to happen here so I'm just going to I'm going to test this path through my code and then maybe test some exceptions and then stop there but at the beginning you might have to test the whole you might have actually started at the beginning say I want to be here and then ask yourself well why am I doing this and then ask yourself it's like that five times ask yourself why and then write a test for that and then continue doing that until you have something that actually works seems repetitive but that's how I think I started and now I think I have an affinity where I can actually don't have to ask myself why so many times because I think I started a lower level but I can actually just say I'm just going to write something here and that should come from here and I'm not perfect yet but I'm a lot closer than I was so my answer is um YMMV TATFT so if not I can say thanks you guys and it's been fun this is the first time I've done this talk so hopefully it didn't suck too bad and thanks