 My name is Brian and I'm here to talk about testing and at first people will probably seen this talk. Oh well, you're going to see it again. So today I'll talk about BDD with RSpec but I like to change things around so let's just talk about BDD or really let's just talk about testing for its normal people. And the real thing that I'm trying to get out to everyone here is you should be testing all the fucking time. So let's get down to the nitty-gritty. Today I'm going to talk about RSpec, I'm going to talk about BDD, I'm going to talk about evolution, I'm going to talk about your feelings, I'm going to talk about politics and I'm going to talk about testing all the fucking time but most of all what I'm talking about is compromise. So let me start this with a little bit of a story. And the Bible says in the beginning, and in the beginning there was what? No, there was Pearl. Pearl is what I knew and you see this is what I used to throw up on my keyboard daily and that's what I came up with. And then after I got good with Pearl I started with Java and this is not my Java but I wrote Java and it looks just like this. So one thing I want to say is test all the fucking time. So then I fell into testing and this is with good old JUnit and I thought I was doing real good here but there was a problem, wow, the problem was I was writing bad brittle tests and my test had no organization and I wasn't using any type of conventions, all my tests looked different every single time and really I was just confused all over the place. So then a couple years ago there was this little Danish guy who looks like a cartoon character came up with something called Ruby on Rails and I can't use the logo because he says I can't. So with Ruby on Rails we got this whole little test directory and there was unit and functions and something called fixtures but guess what, I was writing tests and they were really bad. They really pissed my daughter off. So I started writing more tests and my evolution began and I was writing tests but I wasn't writing tests first. I was just writing tests to make, they were looking like my code basically. So if I had 1 plus 2 I had a test that said 1 plus 2 equals 3 but remember this, test all the fucking time. So one day I discovered TDD and now I'm writing my tests first but you know what, I'm still writing tests based on implementation and they were terrible tests. So beginning of last year, I guess around January of last year some really smart guys came up with RSpec and I thought RSpec was cool and I was like wow this is hot and I'm writing tests just like this. And I'm like why is it so cool? Because I'm testing with context. This is real interesting. I'm actually able to actually put what I'm testing in a way that I can actually read it but you know what I was still doing? I was writing tests with the brittle, funky syntax and it wasn't helping anyone. So I sat and I thought about testing again with RSpec because I wasn't ready to give up on it. So I studied testing and I studied some more testing and I studied some more testing and this is what I did. I actually became obsessed with it. I studied testing and I said I'm going to figure out this testing thing and really I studied and I studied and guess what? Behavior-driven development, buzzword, Eureka, I had a moment. I said this is how I'm going to do it. I'm going to behavior, drive and develop. Or so I thought. So one rule that you should be getting out of this talk is you should be testing all the fucking time and that's really what I'm trying to get here. So back to BDD. What I came up to, my conclusion was that this is a bunch of hocus pocus. It's just the same way, it's just a different way of saying what I was doing to begin with. So coding this way is uncomfortable and there isn't instant benefits. Anyone who's just starting with testing probably going to test this. I probably can have like a prayer revival and you guys can come up here and tell me how bad this has been. So let's talk more about BDD. So what I've come up with is describe what the code should do rather than describing what it does. And whenever I realize this, I actually, it was a moment for me. It was like I reached zen and I really do do this all the time. And I'm going to say this to you. You probably say I already do this. I'm going to say you don't because when you start out testing, you don't do this. As much as you think you do, you don't do this because really it's harder than it looks. So you're asking yourself, where do I start? And I'm going to say test all the fucking time first, but then I'm going to say you can start at the beginning. And so what I've done, because I like to center everything around me, I came up with the smartness guide to BDD. And there's four rules to the smartness guide with BDD. Get comfortable with TDD. If you're not writing your tests first, you're doing yourself, your company, your clients and everyone else at this service. You're killing babies, you're kicking kittens. So get comfortable with it. Make it your mission to do it all the time, even when it hurts. I don't care if you have a deadline coming up. Test first. Write your tests first. Use FlexMock. Use Mocha. Don't use Mocha because it sucks now. But use RR, which I just learned about earlier today. Use that. Use something. And then think of your applications as objects of expressing behavior. We're all Ruby programmers here. So, you know, we really are using OO. Use it to the fullest. Do not do procedural stuff in your OO. It sucks. And then also create examples of those behaviors. Remind yourself to do that always. All you're doing when you're writing your tests is you're creating examples of how you want your code to work. So, TDD is a muscle. You have to exercise it. And I know it's slow. And by the way, this is just something that I tell myself. TDD equals BDD. If somebody tells you different, there's just a lot of hocus pocus. And actually, I pulled this quote from behaviordriven.org. BDD brings together TDD and DDD. Blah. So, let me talk about your feelings while you're going to be testing. And this is something that I felt first. First, I was sad. You know, I was like, this sucks. And then I was like being patient because I was like, this sucks. It takes forever. And then I had grief because I wasn't getting any success with my tests. And then I felt cromulent. I don't know what that means. But then I had disbelief. And that actually is my wife. And she is disbelief that I actually took that picture when she wasn't expecting it. But then, and then it was an important part, I accepted it. I accepted that it would take a little bit longer, but my code would be better. And I'd only have to work on it once where I'd have to go back to it three and four times. So I said I was going to talk about politics, Obama-Hillary. But really, I'm here to talk about painting the White House black. And she's going to win. And another thing is, you've got to remember, test all the fucking time. And I can't say this enough. And really, this is what I want everyone to say. When they hear Ruby, I want you to say, test all the fucking time. Yeah. So I want you to know, RSpec isn't the only way. It's a great way. You know, I started with it. And I'll tell everyone, I quit the day that I had to use R to bug in RSpec. It doesn't work. It does weird, bad things to objects that you shouldn't do. I wouldn't kiss his mother. I'm sorry. But there's others. There's TestSpec. And then there's Bacon. That was written by the guy who wrote Rack. And then there's Shoulda, which is really cool. She's the guy she investigated if you haven't seen it yet. And then there's MSpec. Those Rebenius guys use it. I'm staying away. But most likely, when you came into this, you weren't looking for BDD. What you were really looking for was something like this. We only write code to make our specs and tests valid. And I actually code this way to this day. I think that my output or my specs or whatever I'm going to call them, I write code to make my specs go green. That's really all I do. And when I think about it that way, it's kind of like a game. So I always want to make sure that everything is right. And that's what I'm saying here. You write your specs to drive your code. So what are we going to use? Do we use RSpec? I don't care. Do we use Shoulda? That's up to you. Do you use the other new flavor of the month? That's up to you. Use what works best with you. And just remember, pick something better than test unit alone. And I know Nathaniel's here. So I'm going to say sorry. So this is where I am today. I TDD all the time. Seriously. My guys hate me because I sit down. And the first thing I do is I go to my test directory. Or if I have to use spec, I go to my spec directories. And I write a spec and I watch it fail. And this is something. And this is actually what was written a while ago. I should like RSpec. RSpec syntax is extremely cool. But I don't prefer it. But guess what I do? I test all the fucking time. But I like assertion. So I start that I don't have time for the quirkiness that RSpec gives me. And I'm not saying anyone else. It's just me. So I do have a current combo. I use test unit. I use Shoulda. And I use RSpec story runner. But I got something to talk about in a second about that. And I said I was going to talk about compromise. And that is my compromise because the RSpec story runner is very cool. I love where it puts me. But as of last night, I saw something. So we're going to stop the presses and we're going to talk about a cucumber. Does anyone know what I'm going to talk about right now? Besides this guy. I love this. I love this. So this is a video. And this is and like I say, I have little before I had mice. Now I have little rodents or little bees and they're doing my typing for me. And next thing they're going to do is they're going to go look in a directory. And what I've done here is this is this new thing called cucumber made by one of the RSpec guys. So what I've done here is I'm showing you this new feature, plain text features. I want to see a link for Ruby Hoedown and I want to have that link and I want to have that title. So I'm running this new feature. And this is going to be the new hotness. You're going to hear about this real soon. And what it did is that spec, it launched a browser using waiter and it made my test pass. This is the new hotness. And I want to leave you guys with one thought. Do not try to imitate the old master. Seek what they sought. And this is something that I live my life by and I want to leave you with one more thing. And I just want to tell you, I'm Brian Lyles. I do this blog. It's smart to kiss. I have to tell people I work for source fire. We make snorts cool to open source network security. You should actually get on it. If you don't have this as your corporation, you should get on it. Come find me. And I test all the fucking time. Any questions? Yes. Just to be clear, cucumber is just a rewrite of story runner. Using tree top. So it's not a rewrite. It's a better rotation. Right. But it's also used to demo water with it. Yeah. We can also use with just story runner. Yes, you can. You can. And actually that demo was taken from the source that is actually on GitHub. The most coolest thing ever. Right now I pulled that down this morning and changed some words around. But yeah, all that stuff is there and it works. So go check it out. How often do you test? All the time. Remember a situation where you would not test? No, there isn't. And really there should be. You're not coding. And actually it's something serious. And it's something very serious. I manage a team of developers. And I impress this on them all the time. There is never a situation where you should not be testing first. If you're writing code, you're not testing it. The code is wrong. I don't care if it does the right thing. And people need to understand that. Yeah, if it works by accident, you're still wrong. I'm glad you demonstrated what you do with that pickle. It's a shoe cover.