009 JSJ Testing JavaScript with Joe Eames

Download MP3





CHUCK: Hey everybody and welcome to episode 9 of the JavaScript jabber podcast. This week, we are going to be talking about Testing JavaScript with Joe Eames. Joe do you wanna go ahead and introduce yourself really fast and then we'll do the rest of the introductions and start talking? JOE: Sure. Thanks Chuck. My name is Joe Eames and I've been a web developer for a very long time and I'm the creator of testdrivenjs.com it’s kind of my own personal quest to bring better unit testing and test driven development to the JavaScript world. That’s pretty much me. CHUCK: All right. Thanks, Joe. I've actually had lunch with Joe a few times. I organized lunches for the JavaScript group here. And yeah so I’d organize them up in Murray -- which is a suburb of Salt Lake City and yeah, Joe and I have had one-on-one lunches twice now, I think. JOE: Yup. CHUCK: Yeah, so I might just start scheduling lunch with Joe and then stop scheduling JavaScript lunches at Salt Lake county. [Laughter] JAMISON: That will probably be really romantic though. CHUCK: Yeah we should have lit a candle in the last one. JOE: We should have. CHUCK: Yeah absolutely. Anyway, we also have Jamison Dance on the podcast. JAMISON: Hi I'm Jamison Dance. I'm a web developer and JavaScript developer in Utah. CHUCK: All right. I'm Charles Max Wood form teachmetocode.com. I guess were all from Utah this week. JAMISON: Oh, yeah. CHUCK: Yeah so anyway… so really interesting, for me anyway, is that I used to complain a lot that I would write JavaScript and then I couldn’t test it because I'm pretty accustomed to testing my Ruby code. And so, Joe did a presentation at the… was it the last meeting that we were at or the meeting before that? JOE: The last one. CHUCK: Yeah about doing TDD with JavaScript and I'm sitting there going, “Ooh, this is speaking right to me.” And so, I'm a little curious Joe what your take is as far as how TDD works with JavaScript versus maybe doing TDD with other languages or frameworks? JOE: Well it’s pretty interesting, the difference in opinions and views. It seems like there's  very large amount of people that are realizing, “Oh we do need to unit test JavaScript,” but very few people are saying we need to test drive our JavaScript the way that many people are saying we need a test our middle tier code. So I think the biggest difference by far is in the community. Having them a fair amount of test driven JavaScript, I would say that there's some differences for sure; where some of the tooling is lacking still especially from the stand point of being… from the perspective of doing test-driven JavaScript, the tooling is lacking. But in the end, there really isn’t any difference. In fact, JavaScript has one big huge benefit when test driving code that just about no other platform than I'm aware of, no other language or architecture that I'm aware of has and that is that you can test drive the DOM. And in other languages, you can’t test drive the windows presentation layer that you are writing or the web page in a jsp or in Ruby, you can’t, in Rails you can’t test drive that. CHUCK: Right. And the best you can do from what I can tell is… because there are tools that allow you to test and see if certain things are on the DOM, but usually what they are doing is they are parsing it and you can search it via x path or some other selector. But that’s about it. That’s all you get. And the other thing is this is all static – there's no other JavaScript engine behind it. So basically, if you wanted to test drive your particular DOM manipulation, you have no recourse other than using a browser. JOE: Exactly. Exactly. I mean of course people are testing the browser with tools like Selenium and doing automated testing, but those things aren’t actual unit tests. Mostly they require a lot of visual inspection, manual inspection for them to be effective. And then the Selenium course gives you the ability to at least know if things are working or not, but it’s not the same thing as actually test driving it with unit testing. Of course, Selenium test historically have been extremely brittle, very difficult to write, very difficult to maintain, so having a large suite of Selenium tests, of UI level tests is just not feasible. JAMISON: That’s actually pretty hard to get good coverage of Selenium test. We've done some of that at work and I mean we use them for some things, but it’s a lot easier to test at the code level than at just the user interaction level. CHUCK: Yeah. JOACHIM: Isn’t those though traditionally tied to just one browse -- to the FireFox browser? JAMISON: No, you can run it on IE and Chrome. Selenium web driver works with Chrome. If you install it, there's like a Chrome web driver plug in or something that you install and then it can run on that. CHUCK: Well and I tend to think of those as more full stack or integration tests as opposed to unit tests, because effectively what you have to do is you have to run your app and then on the other end, something is interacting with Selenium or with the browser that Selenium is driving to make it happen. And so, if there's a problem in your stack, you don’t necessarily know that the problem is in your JavaScript. And that’s the bonus with unit tests is that you are able to isolate things and figure out where the problem is. JOE: Right. Yeah. People, not everybody out there understands that not all kinds of automated testing are created equal. CHUCK: Right. So when we talk  a little but about the different types of testing really quickly like unit test, integration test, UI test -- you know, whatever you wanna call them -- I've also heard of functional tests which in Rails they call them “functional tests” but they really are unit tests on your controllers. But what are the different types that you guys have seen and how do you define them? What are the pluses and minuses of using those? JOE: Well the two clear definitions are Unit test and UI test. So everybody knows what a unit test is and what a UI test is. Of course there should be a little bit of discussion about a good unit test doesn’t involve more than just a single component in code and it doesn’t really talk to the outside world. It doesn’t talk across the network or to the disc or to the database. Those are unit test. UI tests are testing the entire application and just automating the UI. It’s that middle level of tests, like what you are talking about Ruby’s functional tests, that there's a few names for them, people call them functional tests, some people call them integration tests. And those are the ones that test right below the UI level going down. CHUCK: Right. JAMISON: So I thought that Selenium test would count as integration test because you were testing the whole stack, right? In order to test your… if you are not just running the UI in some kind of dummy there, like when you are testing stuff with that, you are testing your UI but you are also testing all the backing stuff behind it. So are those not integration tests? JOE: Well it really just again, those definitions are a little less clear across the community. So it does depend on who you are talking to; if you are talking to people that have that really, really, really strict set of definitions probably they'll say that integration tests don’t involve the UI. But there are lots of people who assume that an integration tests does mean the UI. CHUCK: Right. JOE: That is not clear, you know. There's a lack of good definition out there. CHUCK: Right. JAMISON: Yeah I think that comes back to the community problem you said earlier that JavaScript as a community doesn’t have a huge tradition of testing. JOE: Right. CHUCK: So I wanna talk a little bit here about like the different levels of testing then, the UI test, the integration test and the unit test. Just to kind of outline some of the benefits I mean, why you would want to do any or all of them. For me, really unit testing it’s kind of the way of pin pointing where your problems are. Usually they only test one tier and yeah, you isolate them like Joe said. With the integrations tests, or functional tests those are nice because effectively, you can get behavior, you are getting out at the behavior level. But the nice thing with those is that your UI, in my experience the part that’s much prone to change. And so, this is getting anything below there without having the brittle nature of the DOM or whatever as you change what's there. And so this is your APIs that your JavaScript is hitting, things like that and you can make sure that the behavior on the backend is what you expect. And the UI tests kind of give you the full stack so that you can see that the entire app behaves as you would expect under a certain circumstances with certain inputs. Did I sum that up more or less accurately? JOE: I think so. I think that was a really good definition. JOACHIM: I think the different approaches, there are like different types of validity to them. Like for instance, behavior driven development or testing can help you actually design your program. If you are designing from a point of view of, “I want a program that does this that allows you to do these things then I can write my tests right now,” okay you should be able to do these things rather than, “My component can add two numbers together or can out of the database in a certain way.” So I think the abstraction level that you get from like you zoom out so far, that all the problem look small is pretty valuable when you are starting out on a program. JOE: Yeah that’s very true for sure. CHUCK: Yup. JOE: If you look at the different kinds of tests and the kinds of value that they bring, and then the drawbacks that they have, it’s really funny because what seems like is the most valuable is the test that tests everything -- from basically UI-level tests. And you’d think just looking at it from just getting to the subject that, “Hey, UI level test should be the only kind of test we need to write because that actually tests that everything is working.” But when you realize that they are brittle, or slow, that UI changes, all those sorts of things, that your UI tests are no longer that valuable then you look down in the functional integration, middle level of tests that tests at least from a certain point on down. The value there is again very high, but the number of tests that you actually have to write from that level— [Crosstalk] JOACHIM: Huge. JOE: Yeah.   CHUCK: Well that’s because you have dozens of code paths that it can take. And it has to remember for each one and so effectively do a mathematic permutation on that or combination anyway. And yeah, I mean if there are a dozen different code paths that it can take, I mean you are going to have to write at least probably at least 60-70 tests to get each branch. If there are a dozen branches, you know you are going to write tons and tons of tests to get that covered. JOE: Exactly. JOACHIM : And the worst thing is that when you’ve written all those tests and it looks like it should be working but then something changed in the middle and all of a sudden your UI is broken. CHUCK: Yeah and that’s where the unit test and the integration or the functional test come in. JOE: Right. So then if you look down the unit level tests, those are by far the most feasible ones to write. But it is true that they are only as good as they are offering. And it’s a little bit like engineering, right? Mechanical engineering, you can make this mathematical model whether or not a bridge will hold a certain amount of weight, but until you actually build the bridge and start putting load on it, you really don’t know. The math is only a predictor, it’s not a realistic knowledge that things will work. Unit test is the same way. They are like the mathematical predictor of “will it work”. But you don’t know that you glued the pieces together correctly because unit tests, they isolate the pieces, so you don’t know that the pieces work together correctly until you actually get the application running. So it’s important thing to realize that unit tests are not a silver bullet. They don’t guarantee that your application is correct. CHUCK: Yeah but they are a good way of checking your math. JOE: Yeah exactly. JOACHIM : We are talking about all these work involved with JS doc annotations and also we were talking about Dart the other day, where we are getting into more type languages or you can also do that with JS doc annotations anyway. Is it feasible to have automated test scaffolding generation? JOE: Can you be more specific? Clarify exactly what you are asking? JOACHIM : Well, I mean can I be like really, really lazy and then just like write an interpreter that kind of looks at my code an say, “Okay, well you want to put this type of input in here and you want to put this type of input out, so we are going to put a lot of data in there that kind of should fit that and should—“ JOE: So I’ve seen that in one place and the people who thought that was a good idea was Microsoft. So— CHUCK: [Laughs] JOACHIM : Okay. I'm sorry. CHUCK: I see two things here; one is basically where… how do I say this… if you are generating your tests based on the code, and so basically what you do is you automate it so that it looks up the code and says, “This is what it’s supposed to do, now feed values in and get values out.” That inherently… it kind of circumvents the whole point of testing because you should be telling it, “This is what I want you to take in and these are the effects that I want you to have.” You know, be it, “You give back these results or you change the state in these areas,” or what have you. You know, that’s the whole point. So that kind of automated test generation just doesn’t really ring right to me. At the same time, I was talking to… oh, who was it yesterday on Ruby Rogues, we had Dan Kubb on and he mentioned mutant or “mutation testing” where basically it will throw bad values in or you know, change the logic so that it should take different code paths and behave oddly and see if it can make it behave that way or behave in ways that it shouldn’t, using a tool called Heckle -- which is a Ruby tool. And I don't know if there's an equivalent in JavaScript. But you know, that kind of testing I think really does form up your code because in that case, it should either exit gracefully if it’s not getting what it expects you to get or it should throw errors or exceptions where you would expect them to. Or you know, if you pass a valid value then it should give you a valid result even if it’s not within the range of values you expected. And so you can define some of that to kind of firm your code up. But it’s pretty involved process from what I understand. JOE: Sounds like it.   JAMISON: So you guys were talking about like type checking and stuff. There's a program called Typed.js it was on Hacker News about a month ago, that if you do type annotations on your functions, it will generate tests on that. So I mean it has all the upsides of what you talked about already. But you can do it in JavaScript with this program that somebody wrote. I'll link it in the show notes. CHUCK: So one framework that I keep hearing about is “mocha”. What is mocha? Because I haven’t really had the chance to use it. I've heard jasmine and qunit. Is it kind of the same thing? JOE: Well with some of the popular frameworks, what's really cool bout mocha is it looks basically seems like they wrote that for Node first. And they added a lot of really cool features to mocha. It doesn’t work in the browser, but it works basically natively in Node where none of the other frameworks do. You have to put the modules on them, adapters to get them to work in Node where mocha works. Mocha has some other really cool features. In the end, it’s really just another test framework, but… so if you are going to unit test your code, then whether you choose mocha or jasmine or something else, you can still get the job done. It’s all the little extras that make the big difference. So for mocha, one of the cool things is it will do either BDD or TDD style of testing. CHUCK: Oh, nice. JOE: Which is very nice. Yeah, very flexible depending on what your preference is. It does have a really cool feature where you can have it color code the tests as to whether or not they were fast, kind of medium, or slow and help you clue in on places where your performance might be lacking. And then it also has a lot of really cool output – they call them reporters – so that you can gather the results of the tests and display them in different ways. And some of them are just displays in bash, but they also have like a json output, they have the “test anything protocol”, reporter and then of course a web browser. But the web browser one is by far the most lacking. So if you are going to do browser testing, mocha… if it’s going to be your first choice, you might wanna play around with the output yourself and add in your own CSS or something. JAMISON: Mocha does have the “landing strip test reporter.” It’s my favorite. JOE: [Chuckles] Yeah. JAMISON: It’s got a little really code plane pass down the landing strip to test. CHUCK: [Chuckles] That’s cool. JAMISON: Mocha, I used jasmine and I've used mocha. And for async stuff, I much prefer mocha because I really had a hard time getting jasmine to test my async code, maybe that’s just because I'm dumb, but mocha makes it really easy to let the test know when the async stuff has finished and it should actually start validating responses. [Unintelligible] to work in jasmine. JOE: I've never used mocha, but it does really seem like they look at the existing framework that are out there and really are trying to take the next revision on testing frameworks. JAMISON: Yeah it’s good. CHUCK: All right. So I'm also curious, I know that Joe, you’re pretty partial to qunit. What is it that you like about qunit over some of the other testing framework? JOE: Well, I wouldn’t say that I prefer qunit over other frameworks, but it did have a lot of value for what the implantation that we were doing. One of them was somewhat for a browser testing, its relatively similar to an xunit framework, but the only one out there that’s really close to a typical xunit framework is YIU. But has YUI a ton more ceremony in the tests, so that’s why I wasn’t really keen on using YUI. So qunit actually just feels a little bit more like the other testing frameworks I've used on the server side. That’s basically the biggest reason why I chose that one over jasmine. Also at the time, when I was looking around have a little bit easier integration with teamcity, but jasmine doesn’t integrate with teamcity as well, it just seemed like qunit had a few less steps. So that was really the big difference is for me. So I didn’t use qunit because  it was vastly superior by any reason, in fact it has a lot of things that are lacking. It has its fair share of weaknesses just like all of the other frameworks too. CHUCK: Right. So is teamcity… does it include ci? JOE: Yeah. CHUCK: Okay. Continuous Integration. I should clarify for the non-initiated. JOE: Right. For the continuous integration server we were using, which was teamcity. Qunit seemed to be the easiest one; the one that’s most recommended that slips right into teamcity very simply and very straight forward. Although it looks like jsTestDriver is actually even easier so I intend on starting to use jsTestDriver on top of qunit. JAMISON: What is jsTestDriver? JOE: So jsTestDriver, like mocha, it’s actually really cool. It is a testing framework just like qunit, but their goal or kind of what they admit to is they haven’t really innovated on the test side, what they are integrating on the test… they haven’t integrated on the unit testing side, they are innovating on the test running side. So actually getting your test to run that’s where they’ve spent the majority of their effort. And so what they have is the ability… they have a couple of things that you can’t do pretty much anywhere else. The biggest one is you can run a jsTestDriver server and set up slaves for each of the browsers and then when you save your tests and tell it to run, jsTestDriver will run your tests in all three browsers. CHUCK: All three being IE, Mozilla and Chrome? JOE: Right. JAMISON: It’s actually Lynx, Opera and Chrome, yeah. JOE: [Laughs] Yeah. JAMISON: Can we talk a little bit about a work flow for running you test in the browser? Because I've done a lot of server-side JavaScript testing and that’s fine, you just run your own mocha or whatever command to your test. But what is a good way to get it to run your tests that will report them back automatically? Or do you have to like actually open a browser and go to a web page and then expect the output. JOE: Yeah it’s the latter. If you are actually in the middle of test driving your code -- writing your unit tests then yeah, you got a browser open and you are just going back to the browser and keep refreshing it. But in the end, that’s not too much different from server-side test framework where once you run the test, you rather click somewhere in the test and tell it to run or go to your test running page and tell it to rerun the tests. So there's that one extra step that’s the same thing with your unit testing frameworks in the browser-based ones. CHUCK: Okay so I'm a little bit of a command line junkie, so what I'm wondering is there any way to run DOM-based tests on the command line without having a browser opened to refresh or whatever? JAMISON: There is and it is called PhantomJS. PhantomJS is a headless implementation of Webkit, so it’s Webkit but without a browser window. So you can upload web pages in it and then test them and then get out of that but without actually opening up like a browser, it will just start it in the background and then kill it when it’s done kind of thing. JOE: Right and that’s how most of the continuous integration solutions for JavaScript work as well they use PhantomJS. CHUCK: So then if its loading the whole browser engine into… or its loading it up anyway, whether that be in memory or whatever, is that generally slower than just loading it in the browser or slower than running unit tests where you aren’t interacting with the DOM? JOE: Well since generally you do that on the ci server, I don’t know. I’ve never compared it to locally. CHUCK: Cool. All right, one other thing that I wanted to jump on (and I know we are moving to these topics kind of quickly), but I kind of wanna get a solid overview and then you know, maybe we can bring Joe back or you know, somebody who's working on some of these framework to kind of give us the run down on some of the more specific things. What about mocking? I've seen sinon and I think I've seen another library too but I don’t remember what they are. JOE: So jasmine has its own mocking, but a lot of people use sinon. It seems to be the most popular framework out there. There are several mocking frameworks -- dozens, really -- but sign on seems to be the most popular on that most people are using. That doesn’t mean its superior in any way, it just means that's the one that most people have been using perhaps by default. And so what's great of course about JavaScript compared to a strongly compiled language or static language is that, it’s a lot easier to mock things than it is in other languages. So sinon, you just feed sinon object and it goes through and takes every member of that JavaScript object and replaces it with its own function… a new function that it can intercept and watch the call. And then if you ask it to still delegate the call onto the actual implementation that you wrote of the object so rather than having to create a new object by hand, you actually can take an existing object and then utilize that and watch it. And it also of course was JavaScript we tend to use a lot of just plain functions all by themselves, so it will also spy on functions. They are called “spys” it’s kind of a new thing that the server-side frameworks don’t have because most server side languages don’t like to have functions that exists outside of an object. CHUCK: Right. So can you explain the difference between a mock and a stub? JOE: Yeah so in the world of… everybody calls all these kinds of things “mocks”, but I think it was Martin Fowler who took the time to try and come with strict definitions. He indicated that there is… everything is there's broad category called “test doubles” and beneath that, there's all these different things. And the two that most people are used to using with the framework are mocks and stubs. And in reality, most people just use mocks and very few people use stubs, which is in my opinion, the exact opposite of what it should be. People should start with using “stubs” and then only use “mocks” when absolutely necessary. The big difference between a mock and a stub is not a technical difference, even though in most frameworks, especially the server side ones, they actually have a big implantation difference. The real difference between a mock and a stub is a mock is something that the behavior of the object and the interaction with that object that you are mocking is part of what qualifies to make that test successful or not, whereas a stub is only used to guide the flow of the test. So think of it in this way, if you are writing a little component, a little object in JavaScript that's going to make an AJAX call, and you want that AJAX call to either be made if you pass in another object and that object is valid, you wanna check it for validity first and then make the AJAX call to say save that object to the server or not make an AJAX call and return a value indicating that the object wasn’t valid, then you have two code pass. And you'd use a stub to make a specific test take one code path or another. So if you do the object want to be valid, you'd use a stub to say, “Hey, when you ask this object if it’s valid, return true,” but you don’t care that it asks the object that whether or not it was valid for that point in that test, all you care is that if the object was valid, then do make the AJAX call, right? So that’s what a stub is for. Whereas a mock would be if you are mocking the AJAX call -- which you would want to do in a unit test. You don’t want to make AJAX calls because you don’t want to be running or having to run your entire framework in order to your unit tests. So if you are going to mock the AJAX call, then the test only passes if you actually do tell the AJAX component, “Hey yeah go ahead and call the server and take this object that I'm giving you and save it up.” Well the test was successful it’s given the right object and it actually makes the call. So that's what a mock is for. Mock says, “Yes you did make the call and here's the parameters that were passed and the parameters that were passed were what you were expecting.” That’s how you check the validity, make sure that test passes. That’s the purpose of mock whereas stub is simply to control flow. CHUCK: Mh-hm. So, yeah that makes sense. I'm still trying to wrap my head around it, but I think that clarified some of it up. So, one other thing that we seem to be talking about or talking our way around is BDD versus TDD. Does that color your perception of how you write your tests at all? JOE: You know, it really can, but it also depends on… as an organization, are you actually doing BDD? Jamison, you sounded like you had said this before that you guys done some BDD or you preferred BDD. Is that right? JAMISON: I don’t think I said that. I know AJ says that he thinks the difference between TDD and BDD is you put in the word “should”. [Laughter] JOE: Well the framework unit testing level, that’s really most of the difference. If you look at the difference between say jasmine and qunit, other than the fact that jasmine recommends they have this format of putting the word “should” in in your test names, they really function the same. CHUCK: By the way, don’t use the word should. It either does or it doesn’t. Okay? JAMISON: You should not use the word should. CHUCK: No, seriously. This is a pet peeve or mine. Because rspec and Ruby does the same thing and then the next word in the description is always “should” and I'm just like, should? No, it does and if it doesn’t, then it fails! JAMISON: [Chuckles] CHUCK: Sorry I got off on a different tangent; but yeah. I generally agree with that premise on unit tests. JOE: Yeah. I don’t totally disagree with you I find that you should syntax to be a little off. I kind of prefer naming my tests with given when then syntax which actually again does come from BDD. CHUCK: Yes. JOE: But BDD is much bigger than just the unit testing, it really describes more… in addition to the unit testing it also describes how you interact with your business analysts and encourages non-programmers to be able to write some of the tests, not the unit level tests, but higher level like integration tests and that’s where cucumber comes in. JAMISON: I was just going to say I really hate the word “business analyst”. It sounds so dry and boring. CHUCK: [Laughs] JAMISON: Like non-developer basically. I don’t know that any one says that they’re business analyst. Maybe I'm offending all the business… like there's a convention for business analysts that’s going to come to my house beat me up. CHUCK: So two seconds on that real quick. If you don have someone from the business side coming and talking you what the business requirements are, you are the business analyst. JOE: Right. Yeah. CHUCK: So I mean one way or the other either somebody else is making decisions on the highest level of the application, defining behavior and functionality through the app or you are doing it. And so, you know, if you don’t have a business analyst you are the business analyst and you need to be thinking that way. JAMISON: So it kind of sounds like for BDD, you are looking at the app as a user would look at it; where with TDD, you are kind of looking at it as you would develop it so. So it’s like saying for TDD, I need to make this function that returns these parameters and you write your test that tests that. In BDD you say like, I need to be able to click and drag stuff around like as a user, not what functions or things you wanna call. Is that accurate? CHUCK: Kind of. So my take on BDD is that… the mantra that I keep hearing whenever people talk about BDD and when I do BDD is outside in. So you start at the outermost layer and then you work your way in. And so, basically, you start at the functionality or feature level. You break that down into behaviors, those behaviors got your UI and integration tests, but in order to get your UI or your integration tests to pass, in other words, to validate… so basically you are writing acceptance tests as UI or integration or even unit test. And anyway, so you work your way down from the outermost level to the innermost level. So you are saying, “I have this behavior that I want in the application, so that means that, you know, I need this API.” So then you write the integration tests for that API and within that integrations test, where you are calling these objects and these objects need to behave in this way, so then you are writing the unit tests. And so if you are doing strict BDD, you know, where you are using TDD as part of the process, then you are just approaching it from a little bit different angle; whereas TDD, all that means is that I'm writing the tests sort of as acceptance test for my code, except that you’re writing the test to drive your code. JAMISON: So it sounds like BDD is a superset of TDD then? CHUCK: In my mind it is. JAMISON: TDD to do BDD. CHUCK: But some people think of it differently and see them as kind of opposing points of view but I don’t see it that way. JOE: Yeah I agree with that. I don’t think by any means there are opposing points of view. In the great article that Martin Fowler wrote, “Mocks aren’t Stubs,” he talks about the different kinds of TDD-ers or TDD-ists -- I guess it’s what he calls them and— [Crosstalk] JAMISON: It’s pronounced “TDDists” JOE: TDDists. There you go. JAMISON: [Chuckles] JOE: And he talks about the fact that a lot of them approach a program from the outside in, form the UI level down. The mockists tend to do that a little bit more often than the classicists, was the two divisions. Read that article. It’s fantastic article. But you can be a TDDer and doing like what you are saying Chuck with BDD, you start from the outside in and really not be doing BDD because you are just doing TDD form the outside in. CHUCK: Right. JOE: Because BDD has but I agree with you, I think it’s a superset of TDD. And I think it will be hard to do BDD without following the practices of TDD that mostly exist which are write your tests, make it fit, write a failing test, make a pass, refactor and continue. CHUCK: And that’s where you are given when is coming because then you have acceptance test your business people -- business analysts, whoever -- can look at and say, “yes, that’s what I want.” JOE: Right. And the Wikipedia article on BDD is really quite good; talks about these sorts of things and the reason why the inventor of BDD invented when he was doing TDD, just kind of felt like it wasn't enough. And there's that same cycle needed to be happening on bigger levels than just the unit level. CHUCK: Yeah. JAMISON: So can I ask you a question about something to circle back to mocking a little bit? When you say that you… so you wanna make an AJAX request so you will mock the jQuery AJAX request, that’s kind of relying on the idea that  you have this global jQuery object which was manually there, right? And so, inside your tests, you will define $object and then in the $ you put like $.ajax and that will be your stub or your mock. Is that what you were talking about earlier? JOE: To be honest, to do it really right, to really do a good purest TDD form of doing that, there's one of the somewhat lesser known rules of TDD is to not mock objects that you don’t own. And to abstract a way any third party library. So that would include jQuery. JAMISON: So you are saying you would pass in jQuery to this object? Or passing some kind of object that can make requests? JOE: Exactly. You'd pass in a wrapper around the jQuery AJAX that’s a  more pure form of TDD. JAMISON: Because that feels like a really weird API to actually use that function that you are always passing around jQuery. I mean-- JOE: Well I wouldn’t recommend passing on jQuery for all of things that jQuery does, but for when it comes to talking to the outside world -- namely AJAX -- wrapping the AJAX call because for one thing, jQuery isn’t the only show in town when it comes to making AJAX calls and if you do wanna change, then it’s nice; you got this wrapper around it. CHUCK: Well, the other thing is usually, you are not just going to be creating it just to have it there for your tests. I mean what you’re probably going to do is you are probably going to create this abstraction and you are going to make it so that it simplifies all the rest of your code. JOE: Exactly. CHUCK: And that’s kind of one of the bonuses that you get out of a pure TDD approach -- if you wanna call it that -- is that, basically, it’s not just about writing the tests first, it’s about literally driving the design of your code based on what you are testing. And so, if you put these levels of abstraction in there, then you wind up with cleaner code. JOE: That’s absolutely true. That’s a great summary of TDD -- the purpose of it -- absolutely. If you are not driving the structure of your code, then you are not doing TDD. CHUCK: Right. So, Joe are there any other good resources that people can look up and follow for learning more about testing your JavaScript? JOE: Well of course there's my website testdrivenjs.com. That’s getting more and more content all the time and we also are looking for people that want to contribute to that as well or repost articles. In addition to that, there are a few other really good resources that are out there. Most of them are relatively specific or general to TDD by itself, when it comes to merging TDD and JavaScript there’s surprising lack of stuff out there. But you can find articles on test driving your Backbone models and your Backbone views. You can find articles on test driving different kinds of JavaScript, but there are few and far in between. There's no really, really great place. On the test drivenjs.com we do have a resource page that lists links out to some general TDDs stuff plus the one book out there on test driven JavaScript development as well. So that’s kind of it. JAMISON: What is it called? JOE: It’s called Test-Driven JavaScript Development. JAMISON: Oh. It seems obvious. JOE: [Chuckles] CHUCK: Cool. Well I think we’re just about out of time, so we'll go ahead and jump in on the picks. Unless there something else that you want to add or that Jamison wants to ask before we go. JAMISON: No that’s it’s like the thing you say before people get married; “Speak now or forever hold your peace.” CHUCK: Well, until next week. [Laughs] JOE: I would like to throw in again my one more plug that if you are doing JavaScript, and you are not test driving your JavaScript, then you are missing out on better code. CHUCK: Yup. That’s generally true of any code. If you’re not test driving it, you are missing out on just awesome benefits. JOE: Exactly. JAMISON: We didn’t even talk about regressions and stuff. I mean, it’s so much easier to change stuff if you know that you have the safety net to tests. CHUCK: Yeah. JOE: Yeah by far, the largest article on that Test Driven JS site is all about the benefits of TDD and kind of enumerates those various different things; refactoring and actually adding maintenance, those sort of things and the benefits that kind of digs in to why it’s much better to do it with TDD than even just doing after the fact testing. CHUCK: Yup. Absolutely. All right. Let’s go ahead and do the picks. Jamison, what are your picks? JAMISON: My first pick is having my mic unmuted. I think it’s the first week that happens for the picks for me. [Chuckles] My next one is GoodReads, it’s a social website for tracking the books that you have read and want to read. I just think it’s cool to have them all in one place because I don't really ever think about the books that I've read or the ones that I want to read. I kind of use my Amazon wish list, but that doesn’t really keep track of the stuff that I’ve already read. So you can add books that you have read, you can rate them. It has a recommendation engine like everything these days it seems like -- and its pretty good. So that’s goodreads.com. My next one is an eBook called “Bootstrapping Design” and this book for me. It’s for people that aren’t really designers that still want things to look pretty, but don’t want to pay hundreds of bucks an hour for a really good designer. So it’s really to the developer who knows what a good design is when he sees it, but can’t really come up with it himself. It’s pretty short, I think it’s a 130 pages and its $40 right now. It’s just launched a couple of days ago. And it’s a great resource, it’s got sections on typography, on color and it’s really actionable; it’s not really abstract with design principles, which I can’t really. I'm not a designer to just read about spacing and then apply it to a website that I'm working on. So that’s been really helpful for me to improve my design skills. And then my last picks is a band called Apparat. They are really chill, electronic music. I listen to them whiles I'm coding. JOE: How do you spell that? JAMISON: A-p-p-a-r-a-t. It’s not really techno, it’s kind of like… I don't know how to describe it. It’s just chill electronic music. Has some vocals sometimes, but its stuff that I can listen to that is relaxing that doesn’t demand my attention so it’s great for writing code to. Those are my picks. CHUCK: Awesome. All right. I'll go ahead and put some picks in here. The first one is I've gotten hooked on the program called “Things.” I think I picked this on all three podcasts this week. [Chuckles] JAMISON: Oh, I love things. I have that. And I use it a lot too. It’s great. CHUCK: Yeah it’s a to-do list except it actually has all the features I want. [Laughs] I was using wonder List before and the real problem I had with wonder list was that there were things that I wanna make sure I do every day and I need them in my checklist [chuckles] so that I can see them and say, “Yeah you need  to read a business book this morning,” or you know, whatever. And so you know, it’s just real nice to be able to have that kind of recurring thing, but the other thing is it has projects and areas of responsibility in it, so I can assign things to projects. I can stick things in like, “do this with the kids, do this with the wife,” or whatever for family you know, take out the trash -- these kinds of stuff. And it’s in there when I need it to be in there and so, it’s really nice. It actually will sync over wireless with my iPad and so that’s also nice. Apparently they’ve been promising cloud sync for a long time and haven’t put it in and so JAMISON: Thing’s cloud sync is called “put it in your Dropbox.” CHUCK: Yes. Yes. That’s actually what I did. But if you put it in your Dropbox then it won’t cloud sync with your iPad. Like if I go somewhere else, then I have to have it sync over Dropbox, to my laptop and then do the wireless sync. JAMISON: Oh, yeah. CHUCK: So it’s not. JAMISON: Yeah it’s not the real cloud sync but-- CHUCK: Anyway, so, that’s one it was funny because we had like a 20 minute discussion after Ruby Freelancers this morning and we talked about books, [chuckles] I swear 20-25 minutes before we ended the podcast during picks. And so I was going to pick Good Reads but I'm sure I can come up with something else here. Have I done the rundown on my podcast setup? I think I have on my show. My other pick really, is I'll pick the iPad. I don’t have the new one, I really want the new one. (Yeah, generous listener.) [Chuckles] I'm just kidding. So yeah, I just love it. I usually just use it for media consumption and not even for like books, because I have a Kindle and I think Kindle is far superior for reading on. But, it’s really nice for when I just need to watch a show or if I need to just kick back and play Angry Birds or something. It’s got that huge screen on it. It’s just really nice. And the other thing is that I can actually prop it up next to my computer and so, if I don’t wanna pull up things in my computer, I can actually just turn it on. And that's usually what I have running underneath so that I can start checking stuff of. So it’s just handy that way. But anyway, those are my picks. Joe, did we warn you about picks? JOE: Yeah. So my first pick is board game called Last Will. Yeah it’s really fun. The point of the board game is that you are super rich old guy that’s getting close to die and so you wanna spend all your money before you die so you don’t leave it to your kids. CHUCK: [Laughs] JAMISON: Oh, like my life? JOE: [Chuckles] Yeah. And so you try to get rid of all your money and whoever does the best job of getting rid of their money by the end of the game, wins the game and that’s just really fun. It’s just kind of set through the 1920s type setting. CHUCK: Oh, nice. JOE: Yeah it’s for really fun. So it’s my first pick. My second pick is the TV show “Psych” which is about a guy who’s really, really smart and he pretends to be a psychic detective. It’s a hilarious show; tons, and tons and tons of 80s references. So love that show. And then my third pick is a book by Glen Cook called the Tower of Fear and it’s not one you can find on Kindle, it’s a rather old book you know, 80s -- so super ancient really. Possibly in my opinion, the best book, best fantasy book ever written. CHUCK: I love how you talk about the 80s and say ancient. I think one of us was born in the 80s. JAMISON: Really? CHUCK: Yeah Jamison. Yeah. JOE: Oh wow. CHUCK: The other two of us are old men. JAMISON: Yup. It’s funny because on Ruby Rogues Chuck, you are like the young man. CHUCK: I am. When we started, I wasn’t the youngest but Peter got out and yeah, now I am. JOE: Let me throw out one more pick, just really quick. There's the TV show Touch with Keifer Sutherland, starts up tonight. I saw the preview for it. It was really cool.  So, I'm excited for that. CHUCK: Yeah they had that first… how long was it? Was it just an hour? JOE: Yeah. CHUCK: Yeah it looks good. I'm really, really, picky about my TV and it wasn’t compelling enough to give up an hour a week for, so what I'll probably wind up doing is wait until they release it to Netflix or DVD and then I'll just watch them all. JOE: Well you definitely need to check out Psych. CHUCK: I might have to. My sister was watching it the other day but I didn’t get into it. Anyway, but yeah, I could just spend that one episode was an off episode because it seems like every show has those. So we'll see. All right well. Thanks for coming on the show, Joe. JOE: Yeah, thanks for having me. CHUCK: And you know, its super awesome to see the testing kind of getting some attention in the JavaScript world because I think it’s one area that a lot of people makes excuses not to use it in. I think there's some real need for it to ramp up and people to get serious about it. JOE: Absolutely. CHUCK: And I think it’s a real sign of serious development going on in JavaScript, so that’s exciting. All right so, we are in iTunes. Like I said before we were in New and Noteworthy, I don’t know if that was in the preshow or not. But we were in New and Noteworthy, so I just wanna thank everybody who has been subscribing and leaving reviews and stuff because we really, really, appreciate. It does help up move up. It will be kind of fun to see this show overtake Ruby Rogues. But we'll see how that goes. Anyway, so if you go into iTunes, you can leave us a review or just a rating -- either way. Tell your friends so they can subscribe. If you are on a device that is not an iTunes device, namely like an Android phone or something, you can go to the website and just use the RSS button or link, then subscribe there and that should actually get you into… then you can get it automatically on your phone or whatever. Other than that, I'm thinking about starting a book club on this show, kind of like what we do on Ruby Rogues. So if you have any book suggestions for books that you want us to cover and talk about, then go ahead and put them into the request a topic on the website. You can either click the feedback tab that’s flipping around on the page somewhere or you can click on request a topic. And then just type in book club and then the name of the book and yeah, within the next few weeks we will probably give that a try and just pick one of the books that people are suggesting. So with that, we'll go ahead and wrap this up, and we'll catch you all next week!

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.