 Cttt.rogu.com, yes, you're probably going to have one too few or one too many, but we'll get it right eventually. This presentation was originally called Penny Tools, Penny Test, just because, well, I like the, oh shoot, I forget the other advice someone else can call out. Literally, yes, yes, that's it. Before I say anything else, I like it when people interact with me during the presentation, so that way I'm not doing all the talking So feel free to ask questions. Don, you really don't have to hack a little bit back there, but if you feel so inclined. So, this presentation was originally intended to be trash and testing tools. So I guess I should have asked the question before I said this. So I wish you guys out there loved your cover. Come on, I know you do. Yeah! Exactly! It hurts. It hurts. But I made my piece with it in the process of preparing the presentation. I did a bit of research and talked to a lot of people. I thought about this. And so, tolerance for tools triumphs in the end, but we'll get there eventually. So who am I? My name is Evan Light. I've been a developer for 15 years, blah, blah, blah. Going in C, C++, Java, I'm sorry, Pearl, I'm sorry again, Ruby. I've been test obsessed for quite a while, and my first phase of being test obsessed came from J, again, forgive me. But I'm here to talk about, yeah, maybe we need to make that thought a little bit smaller. How about that? What I think I'm here to talk about is holistic navigation or mindfulness, forgetfulness and simplicity. So when I say DirtGently-style navigation, who here has read DirtGently's holistic detective services? That's not bad. I've tried several times. I can't get through it. But I got through enough of it, enough times that I read the bit where when DirtGently's lost in his car, he just follows other people around because surely they're going someplace interesting. So he'll get where they're going. Well, he'll see something interesting. So this is sort of how my TV education really began. I started back in job hell. Job, of course, as you may already know, is that the type. So when you want a TVD, you can write your test, but then you have to write a little bit of code or you can't compile it, you can't test anything. Blah! So you get into Ruby. Once you're else from 2007, and someone introduced me to Arspect, and I thought, hey, this is cool. It reads like English. You can just write your test first. Great. David Shlinsky, who's the primary retainer on it, he breaks some really great blog posts. If you haven't read his blog, there's a link in the slides. You can access the slides. Click away. Enjoy. He writes all kinds of great posts about, while he calls it TVD, I think it's a loaded term. I just like calling it all TVD. But he writes some great educational posts. Also, I did a link with Jay Fields, who were for thoughts for a time, now also works with David Shlinsky. He has some really great ideas about testing back when I was learning up on TVD. So those two together, plus talking to other people, plus making lots of stupid mistakes on my own, helped educate me a lot in TVD with RSpec. Then I found RSpec's story runner. A story runner was the first Ruby tool that I was aware of that provided people with benefits and tax in Ruby, and with the intent of facilitating outside and develop, or I think as David was calling it, then started calling it acceptance test, A-T-D-D, A-T-D-D, or A-D-H-D, or any event. So the point being, you test how your application works, from the outside in, if you get all the features, you have all your user stories captured as features in RSpec's story runner, they all pass, and your application works. This applies a little bit in the face of the Brian Holkamp who was talking about it yesterday, to a degree, but that's not saying you don't write anything in test. That's a different matter. So I got the test unit eventually, and I found both of them. I liked testing the R and A-Li Darspec. I didn't think I would, it break too much like Java, the API at least. I don't know how many of you guys can say that you actually looked in test unit in the Ruby 1.8 implementation? Really? That's it? Okay. So if I say that the code's really ugly, am I missing not-in-heads? Okay, I see at least one not-in-head. Yeah. The test unit implementation is really pretty hideous. If you want to do anything to it or with it, beyond using API, not much fun. In fairness, the Vane and Talbot was the often-rooted, just after we converted Ruby, so it looks like Java code was written by a Ruby user. But in the end, it was in Ruby 1.8 for quite a while. But the API is really simple, and the learning curve is really short, and that was one of the reasons it was appealing, to Rubyist. They were certainly very new to doing test-first, and especially very new to doing TDD, so better that than trying to teach them RSVAP. But then QCover came along, and QCover, how many people here who's QCover again? Will you see those hands again? Yeah, you guys know what QCover is. For everyone else, it's an external BSL. That means it's a language that is not Ruby. It's not currently complete. You can't solve any arbitrary computational problem with it. It is specifically designed for you to express requirements, which then map to regular expressions, which then maps blocks of code, which then actually try to test something. If that sounds like a lot of indirection to you, that was the impression that I got from it. I tried using it. I really wanted to love it, and it just pissed me off. So slates, anyway. For any of these testing tools that I've described, how many of you guys have looked in Slash Live for those gems, for RSVAP? You looked at the implementation. QCover, anyway. Okay, not as many people. What I point out to you guys is, if you're doing more than the most basic... Well, let me ask a bigger question. How many of you guys are TDD-ing already? Be honest. Pull again. Yeah. Well done. How many of you guys are really TDD-ing? See where hands go up. Okay. That's fine. It's okay. For me, testing is really kind of an obsession. It's maybe a much better engineer without writing my test first, especially for them without TDD-ing. My designs aren't as good. I had a lot of bugs. I recommend you guys focus on it more. But all that said, you should really look at how these tools work. A, there's a lot to be learned. B, you might see that there are things in there that you don't approve of and makes you not want to use them quite so much. But there's more to that. We'll talk about that a little more in just a minute. So, I talk about being mindful. You've seen this quote before. Wayne mentioned it. When you create things, you can come to find where your case is, rather than your ability. Your case is only narrow. So, create. Well, I really didn't like you cover. And I eventually went to you cover for a bit and I thought, well, fine. I should just go try to make something. So, when should you try to create something? Wayne was talking about this a little bit yesterday. When you have a complicated set of steps to perform that you perform repeatedly, well, that's the beginning. The one that I add really is, when you're using an existing tool, but it doesn't feel right. This is what I talk about mindfulness. When I'm working, I try to pay attention to, well, my mother thinks, how frustrated they have been any given time. I once saw Brian American tweet something I wish I could find it. It was brilliant. Where he said, essentially, the life of a programmer is seven and a half hours as you're working an eight hour day. Is seven and a half hours a day of Peter telling you you're an idiot, punctuated by 30 minutes of gratification. And so, if you're working with a tool that's making you feel like a idiot on a regular basis, it's possible, and maybe quite likely, it's not you, it's the tool. You might want to consider that. Don't necessarily play yourself. So, maybe you can do better. The other point that I make is that we have a bond with our tools. We invest in our tools. So, if you're using RSpec in a project or a cucumber in a project, how easy would it be for you to switch over to a completely different testing ground? Not easy. I'm sure some of you have tried. I know some of you have tried. If you're using testing already, you use RSpec, you want to convert all your specs, that's very expensive. Usually, in projects, I see where they try to do that. You just leave all of your old specs in place. You run that rate test, that rate test, you run the new rate test, and you run both test rates. Well, that's great, but it's not particularly maintainable. So, I wrote this Cuda thing because I didn't like cucumber. I wrote it for me. A few other people have found it to be useful. That makes me feel good. Cucumber tries to be an easy tool to help you communicate with your customer, that essentially will help them write your specs. Most of the time when I work with customers, I end up talking to the customer, I write the spec, I might get them to improve the spec, or I try to get them to improve the spec, and then I build it. So, in that case, I need tools for me. Cucumber is not aimed really at us. It's aimed at the people we're working for. So, I don't really need to go into more graphic detail on that Cuda. You can look, there's a link to it later in the presentation. You can go look at it if you want to. That's not the point. The point is, this presentation is about you. Why aren't you writing your own testing tools? You could roll your own. It's really not that hard. Probably spend a lot of time, I want to see if you're going to get it. How many of you people spend at least half your time writing tests? Okay, that's at least a third of the audience. If you're spending that much time writing tests, if you have any discomfort with the tools you're working with, why don't you try to find, or do you try to find better tools? Or maybe you should think about making your own. It's the whole notion that if you spend so much of your day awake and doing your job, and you're doing your job and you hate, why are you doing that to yourself? That's like punishing yourself. You're supposed to make your life easier. So building a testing tool is not particularly hard. There are about three different things too. You need to be able to define a test. You need to be able to create an environment to run the test. And then you need to be able to define a assertion mechanism or an expectation mechanism to say, well this thing should do this. And so this is really very little stuff. So a few days ago, I wrote this little crummy thing which you can probably barely read, especially if you're watching the camera. It's predictably called editing test. And it's 42-1 to code. So it's the answer. It's clearly the answer you used, but no, I'm kidding about the answer part though. But it's 42-1 to code. It's not particularly free, but it has failures. It has errors. It has an assertion mechanism. It has a runner. This is not hard. It's something everyone I think should try to do. Just because you should realize that a lot of tools we use, at least the basics, are pretty simple. So a trend that I noticed for me in terms of my TDB journey is I started by following the community in that dirt-gen name approach. I wasn't sure where to go. I started looking at what everyone else was doing. I did that. I talked to people. I observed what they were doing. I tried mimicking. And then I adapted. I experimented. Ultimately, I got to a level of sophistication at least where I felt the need to improvise with it, to try something different. And then that seemed a little familiar to me, skipping ahead a little. That seemed to me like the driver's model of skill acquisition. Have you guys heard of this before? Get to the end of something. There we go. Okay, so some folks have heard of it. This crack-off book, there's also a link. No, I don't get the money for it if you buy it. Any one of those. But the crack-off book, crack-off activity, and learning actually Joe spoke about it six months ago when you taught. Basically, one of the other things talks about this model skill acquisition where you are a novice. You're a... I can't remember all the steps. But the point is it's a process of becoming, going from a novice to a master supposedly. Or at least they use the term master. And you start off by broke, and then ultimately you end up getting the free and the improvised. So, moving on. Forget about this. What I remember to test you, this is what I basically use to test you on a day-to-day basis. Four and a half months. Maybe a cert equal, a cert instance of, and a conditionally a cert match. I almost forgot that was in there. And if I recall, testing was probably a guy who had 15 different certs. When I used R-spec, I used shouldn't you should not, and really I used three different kinds of matches. Equal, not equal, and then all the dynamic points. That's it. So, thinking on this, there's another trend here. I remember what I used. I don't use it much. I forget everything I don't use. So the curriculum principle occurs with me here. That the majority of the work is usually done by 20% of something, the other 80% does the remaining 20%. So, that's the minority of work. So, I'm using maybe 20% of testing it. When I was using R-spec, I was using maybe 20% of R-spec. Assuming I'm not even special Stofling, I imagine that this applies to you as well. So, that means that testing tools can be 80% simpler potentially than they are right now. And also, that people who write tools really like to solve edge cases. Now, that might be a euphemism for saying that people who write tools tend to really like to write complex tools. We like to do everything, right? We like to make everyone happy. But, it's not necessarily the, it's not a simple approach. Feathers was around earlier, but he tweeted yesterday that simplicity is a cognitive load in code of thing, not a code of thing. Reason, I forget, at least, so much of the APIs that I use, is because remembering all that is more cognitive load. All the files that I have to deal with in the applications I work on, that remembering them is cognitive load. All the classes I deal with are cognitive load. Remembering which tests test which classes are cognitive load. We've had a lot of crack when we have to remember on a day-to-day basis doing our jobs. That's tough. So, why do we need these really complex tools that try to do everything? So, what's the right tool? And then, this was just an attempt to provide a QT given when then an example of defining it. But really, for a test, you need the ability to a tool that will help you design things or you need a process that will help you design your application that will help you communicate the features that you're trying to build and that will obviously allow you to actually test those features. So, just going through those in a nutshell we're talking about that in a nutshell for design the technique is more important than the tool. You know, ARTSVAC testing unit, Cucumber, Shuddha, well Shuddha is some bad tool, but whatever. If you've ever studied martial arts before, and I've just been a while since I have, if you've ever studied martial arts before you've probably seen, you've probably heard or experienced that as you improve the people who get really good at it they might say that in the end it doesn't matter which martial art you master as long as you master one of them because they kind of approach the same place. So, it's more about it's more about the technique than the tool is more about the technique than the particular art. But in terms of picking a tool if you were a beginner then taking a particular tool may help you. And the reason for that is that if there is a strong community behind a particular tool if you're new you can learn from that community like I was mentioning earlier as far as the process of skill acquisition it's very hard to teach yourself but if you have good people to get exams from you can learn from those people if, so in that case while I was giving everyone a hard time about cucumber earlier cucumber to me makes sense our perspective to me makes a lot of sense especially for people who are new to testing who are new to TBD because there are other people in that community there to support you you start to go in on your own pick less common tools or a joint tool you're going to be a lot more on your own at that point so getting back to talking about communication your testing tool is also a specification tool if you're trying to TBD so if you want to bear in mind who am I writing these specs for am I writing them for me, for my dev team for my boss, for my client it's really important who is writing those specs am I writing those specs in my case I usually am do I have a customer QA team who's writing those specs which is called Ruby that's why we're all here but we have these tools that try to obviate a lot of our need for Ruby that they try to provide a complete solution so you never have to leave their magical DSL then but I contend that again 80-20 rule applies that you could use a much simpler tool and then that other remaining 20% of the work you could do it yourself it's just Ruby so my suggestion choose a testing tool that you're comfortable with play with it find your 20% if you can improvise for being 80% or possibly write your own tool so before I wrap up while I talked about testing tools this is really an alloy for a larger concern this is not just about testing tools most tools in the Ruby community unless they're implemented to unless they're trying to implement to a specification that's the one exception I think those tools in the Ruby community try to do too much they try to encourage you to work just within their constraints that we can that we should expect a little bit less from our tools and maybe we should just make a little bit more effort on our own don't try to use your whole tool maybe try using just a little bit of programming things but improvise just a little bit play a little bit so Mod's tools can still be powerful you can build everything all the assertion needs to test you you can build every one of them just using assert basically everything in our spec you can build with should people and should not people and then to extrapolate a little further I think a really good example is Unix itself some of the small tools that play together around a larger kernel Ruby is essentially our kernel we have a bunch of really some really small gems we have a bunch of really big gems that we use on a day-to-day basis maybe we should have our nice big kernel that's really awesome and a bunch of little tools that play well with each other around so I'm just going to say clothing I also curate and run this Hong Kong run through BD camp that's at the end of September there's one day Cobertree you don't know what Cobertree is I'll tell you about it later in two days of conference it's actually, oh my god, outdoors a big blue room and it's completely free it's provided for you actually need sleeping cabinets so you don't have to sleep outdoors so if you're interested you can go Google it or you can talk to me about it later I've got some links here for additional reading if you're interested there's a few different testing frameworks I suggest you might want to look at the APIs, you might also want to look at the library I mean, the ClashLib and then just usual thanks thanks for listening, hope you guys got something out of it if you have any questions you can hold me back those of you who are still awake because I know it's been a long time Wayne! So, you said earlier that the Evan test has insertion support that means that it's fundamentally meant to communicate with you No, I would say it has insertion sorry and you're trying to heckle me with referencing to you no no, insertion it has an assert method that's it assert, yes, correct cursing isn't a funny thing oh right, that's why there's a little bit of giving and that's it any other questions? yes do you need to just less testing overall? because I mean if you download a gem you want to make an addition to it or something like that you go around the space and test whatever if I know what I'm looking at I'll go ahead and add a spec if somebody builds around a testing library I don't know how to run it I'm not going to mess with it don't misunderstand me when I suggest you use predatory own tool you need a way risk of using that tool as well for a lot of people here in Sherwood for startups I feel like for startups too you don't want to use something that's completely untried and prove it necessarily unless you wrote it and you're there to support it and you know you're there to support it other people in your team would create a good idea I don't tend to speak in absolute so anything you hear me saying there's a caveat of usually it depends I do not speak in absolute I think you should write your own testing tool and you should write your own web framework now whether or not you use it in production for every application that's a separate question but it's very educational another example I wish it was recorded but Charles Max Wood did a great presentation for the web conference where basically he wrote a mini Rails framework entirely top of rack where a demonstration of how it would be done in the context of a 45 minute presentation I wish I need to do that I don't know why I would leave that on top of my head do you anyone else want to have a question no wait, there's a hand oh, there's a hand, sorry I'm glad myself spending so much time doing it and like you mentioned I get a little discouraged with the remote I'll let you back to me in a second and you mentioned the most important thing is not what tool you use but what technique personal experience that you'd like to leave about, let's say a point at which you just went too far and you decided no I've got to chill it out with how much I'm writing tests just talk to your ideas about technique oh goodness that's a different presentation I actually did a talk can you repeat the question the question was I was pointing out how you should pay attention to our frustration level and then, sorry, your name? Brett Brett was remarking that he needed so frustrated with his testing that he just wanted to stop if I ever got to a point in working on tests where I needed to dial him down because I just felt that going too far with it I remember this company where I first stopped testing it I had to write in macros when I say macros I just need a class method where I usually class method but just trying to encapsulate repeatable steps from tests and when I started to get two or three levels of deep macros I knew I was a deep trouble because when I couldn't unravel my own macros I knew that was a problem if you want your tests to be maintained you have to know what it's doing you can't do that and do something wrong and at the same time for me when I'm writing a test if it's not if it's not immediately obvious not to test a particular piece of a particular class either it means that I'm dealing with a problem that I've dealt with before or that I probably did something wrong earlier and maybe I need to readjust a little bit about it in a little presentation 2009 a lot more clueless like when I drop it and I guess that's it thank you