JavaScript Jabber

JavaScript Jabber is a weekly discussion about JavaScript, front-end development, community, careers, and frameworks.

Subscribe

Get episodes automatically

067

067 JSJ Testem with Toby Ho


Panel

Discussion

00:53 – Aaron Frost Introduction

02:45 – Toby Ho Introduction

03:06 – testem

04:43 – Integration Tests

06:32 – guard

07:49 – The testem UI

09:55 – The Browser Launcher

11:40 – CI Mode

12:27 – Is it a Global Installer?

13:39 – Workflow

  • Grub Filtering
  • testem.json/testem.yml
  • Devmode
  • Exclusive Tests in Mocha
  • Karma
  • .only
  • Console Logging

21:27 – Debugging

25:25 – testem vs Karma

28:08 – Testing JavaScript

29:50 – Browsers

30:54 – Configurations

32:11 – Contributors

33:33 – Grunt.js

35:09 – Testing & TDD

Picks

Book Club

JavaScript Allongé with Reginald Braithwaite!  He will join us for an episode to discuss the book on August 1st. The episode will air on August 9th.

Next Week

ES Next with Aaron Frost

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]  [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]  CHUCKHey everybody, and welcome to Episode 67 of the JavaScript Jabber Show. This week on our panel, we have Joe Eames. JOE:  Hey there. CHUCK:  We also have Aaron Frost filling in for us. AARON:  Hello. CHUCK:  And we have a special guest and that is Toby Ho. TOBY:  Hi everyone. CHUCK:  I’m Charles Max Wood from DevChat.TV. Guys, why don’t we have you introduce yourselves really quick? Let’s start with you, Aaron. AARON:  Okay. So, I’m a frontend developer at Domo. JOE:  Open-source evangelist. AARON:  Well, you can call me whatever you want. [Laughter] AARON:  I’ve worked here for a few months. I love it. I’m writing a book on the next version of ECMAScript and a dad with three kids. So yeah, that’s me. JOE:  Aaron’s too modest. He’s also a big-time conference speaker. He’s a regular presenter at local user groups. And like I said before, he’s one of our evangelists, so he was hired as a really high-level frontend engineer here at Domo to help us take our JavaScript and frontend work into the next level, really. CHUCK:  Yeah, I also showed up late to a workshop that he was putting on using Node and Twilio and that was pretty cool. JOE:  Yeah, that thing has been the bomb. Also, Aaron’s presentation at Fluent Conf with Dave Geddes was apparently the hit of the entire show, the best received. The organizer said he thought it was definitely one of the best presentations done at Fluent Conf. AARON:  Yeah. They said it was the most entertaining and Simon said he wished we could cut it down in ten minutes and that they had made us keynote, because it was pretty fun. We had a lot of fun with it. CHUCK:  Cool. JOE:  Yeah, it’s up on YouTube. We’ll put links in the show notes. It’s really great. They actually shocked themselves during the talk using electrodes. AARON:  I even got Nick Zakas to get up there on stage and shock me. So, it was pretty fun. CHUCK:  [Laughter] You wouldn’t even have to pay me to shock you, Aaron. AARON:  I know. Well, I didn’t have to pay him either. I know a lot of people who, actually, I wouldn’t have to pay to shock me. [Laughter] JOE:  There’s also a short of Dave shocking Paul Irish, right? AARON:  Yeah. TOBY:  I saw that online, too. [Laughter] AARON:  Yeah. CHUCK:  Alright Toby, why don’t you introduce yourself? TOBY:  Yeah. I am also a father of three kids, so yay. I brand myself a JavaScript hacker. I live in Atlanta, Georgia and I organize a local JavaScript meet up there. I’m also the author of Testem, which is an interactive JavaScript unit test runner. CHUCK:  Awesome. We brought you on the show to talk about Testem. Do you want to give us a little bit more in depth explanation of what it is and what it does? TOBY:  Sure, I’d love to. It is a command-line tool. Like I said, it’s a unit test runner. It has a development mode and a continuous integration mode. Dev mode is designed to streamline your test-driven development workflow. It has a text-based UI, akin to ncurses apps. You draw the UI with ASCII characters and it even has tabs and panels and stuff like that. It’ll monitor your source files for changes and rerun the tests for you whenever you save a file. That part of it is inspired by Autotest and guard in the Ruby world. It is test-framework agnostic. Out of the box, it will support Jasmine, Mocha, QUnit, BusterJS, and it can run your test in all the major browsers plus PhantomJS and Node.js. The continuous integration mode is designed to be used on a CI server, which will rerun your tests whenever you check-in any code. Then what that does is it’ll iterate through all the browsers you want to run your tests on, one by one, and then finally report all the results. CHUCK:  Nice. That actually sounds like something that I would really, really like to have. The question that I have is regarding, for example, the front-end tests usually require some kind of DOM, some kind of user interface. How do you get around that? TOBY:  I think you had Justin Searls on at one point. I think he did a pretty good job of explaining the approach that he takes. Actually, to be honest, for UI work, I tend to do more of end to end integration tests rather than unit tests for those, because for me UI, a lot of times, you’re not sure what UI you want to begin with. You have to see it and play with it to really know. And then afterwards, you’re going to want to make a lot of changes. I don’t go test first when I am creating a UI in a lot of cases. Then when I’m happy with what I’m seeing, then I’ll go in with an end-to-end testing tool. My tool of choice at the moment is capybara, which is Ruby-based. JOE:  So you don’t use Testem for your integration tests? TOBY:  I actually do. I actually drive the capybara tests from Testem, just because I do everything in Testem nowadays. JOE:  Is that something that’s easy for everybody to do, or you feel like you’re doing it because you know Testem so well that for the average layperson you wouldn’t necessarily recommend it? TOBY:  I think it would be on par, more or less, with a guard sort of setup. So if you’re happy with a guard setup, doing that, there’s probably not a strong incentive for you to switch. JOE:  I’m not familiar with the guard setup. What is that? TOBY:  Guard is another Ruby-based. It monitors your source files and on save, it will do something for you. CHUCK:  Yeah, I use it with my Ruby projects. Guard basically, you have plugins for it. The ones that I use the most frequently are the rspec plugin and the bundler plugin. When I update my gem file, it will re-run bundler and install any new libraries or new versions of libraries that I tell it to. Then I also use it with rspec. So if I save a file, then guard will automatically run the related spec files for me. TOBY:  You can, from one perspective, you can think of Testem as like guard with a fancier UI. If all you wanted to do is to run some shell command if a file changed, you can use Testem for that. Then it’s just like a fancier guard. AARON:  You wrote this in Ruby, then, it sounds like? TOBY:  No, this is written in Node. AARON:  Wow. Okay, cool. JOE:  That’s cool. I have a question about the UI for it. I saw a demo a few months ago and the UI was, I want to call it a little like 8-bit-ish. TOBY:  It’s very retro. JOE:  Yeah. Did you do you that on purpose or was it because you’re not a designer and so you defaulted to that? TOBY:  I don’t know. I am definitely not a designer. I don’t know. I’m trying to imagine what a designer would come up with, in terms of a text-based UI. [Chuckles] TOBY:  I don’t know. I actually did do several mockups, like just in HTML to compare, and then I chose one. This is what I came up with. And about how I implemented it, actually initially there was an ncurses binding for Node and I used that initially. But the biggest problem with that is that it requires the user of Testem to compile some C code, because ncurses is a C library. That’s slow, for one, and second, it won’t run on Windows at all. Then I found this module called charm that James Halliday wrote and that doesn’t require any compilation whatsoever. It’s pure JavaScript and it’s a couple hundred lines. That’s it. So that works fantastic. JOE:  Very cool. AARON:  Yeah, I like the retro look. I thought it was pretty cool. I think you did a great job. TOBY:  Thank you. JOE:  Do you get mostly positive feedback about your UI? TOBY:  Yeah. I actually don’t get too much feedback about the UI itself. [Chuckles] TOBY:  But yeah, I like it and the feedback that I heard about that, they like the UI. I do get a lot of feedback about, “Oh, the browser launcher feature is so cool,” and other stuff and using it with CI and things like that. CHUCK:  So let’s talk about the browser launcher here for a minute. It actually will fire up Chrome or Firefox or whatever you’ve got on your machine and run your tests in the browser? TOBY:  Correct. Yeah, it’ll look for the executables for the browsers at their default installed locations. It’ll figure out whether it’s there. If it’s there then it’ll try to run it, basically. And I’ve figure out where all the locations are for all the different browsers on Mac and Windows and Linux. CHUCK:  I’m just wondering. If you have Chrome and Firefox and Safari, let’s say, it’ll run all of them every time? TOBY:  In dev mode, it won’t run. By default, it actually won’t run any launchers for you. You can configure it to in the configuration file. You can say when you run Testem in dev mode, then launch Chrome for me, or launch PhantomJS for me, or you can also configure a custom launcher. In continuous integration mode, it will try to launch all the browsers that it can, because in my opinion in dev mode, you don’t care so much about exhaustively testing all the possibilities and in CI mode, it’s like whatever, it’s doing it offline so it can take as long as it wants to. CHUCK:  Gotcha. So in CI mode, is CI mode designed for the other CI systems like Jenkins or TeamCity or whatever or is it its own CI system where it does all the runs for you? TOBY:  It’s definitely designed to work with something like Jenkins or TeamCity. I’m not quite that ambitious [Chuckles] to build my own CI server. CHUCK:  So it doesn’t trigger itself to run the tests? TOBY:  No. It’s basically a command-line command. You run it. It will output the test results in TAP format, which stands for Test Anything Protocol. At the end, if it fails, it’ll exit with a 1. If it passed, it’ll exit with a 0. CHUCK:  Gotcha. AARON:  I’m wondering, is it a global installer or am I allowed to have multiple versions of Testem on my machine. Like in a different project, if you were to update and release Testem, could I have both versions on the machine, one for each project? How does that work? TOBY:  You can do either. Actually, it’s very much in the spirit of npm. Npm has a Global mode and a local mode. Global, you’re just going to install it globally into user/local/bin or something like that. This is what I usually do. I just run it globally. But I have talked to people who like to install Testem within their own projects and that’s the local mode of npm, which is the default actually. So if you just do npm install Testem within your project folder, if you’re working on a Node project, then it’ll install it into the Node modules directory within your project. AARON:  Gotcha. That’s cool. So Joe and I are sitting here talking. We’re wondering about the grub filtering. Is there any way we can tell it to run a certain set of tests or does it always have to run the whole suite? TOBY:  There’s a source files configuration in the configuration file. The configuration file is usually called testem.json or testem.yml if you want to use YAML. You just specify the source files as an array and the array can accept a glob format, so you can use wildcards and stuff like that to match the set of source files that you want within a directory or so forth. JOE:  Being that it’s a config file, I assume therefore it’s not necessarily very easy to make changes to it without basically opening it up and messing with it in a text editor or writing some kind of facility. So I can’t say turn it on and just filter these. And then, oh, I want to switch the set of tests that I’m running so turn it on and run it for everything. There’s nothing like I can just add a command-line parameter or anything like that? TOBY:  Yeah, you’re correct. But the way I like to do that is not via the command-line. This consideration is influenced by the way that the dev mode works. The dev mode, this is how it’s meant to work. I would just open up, just run Testem in the terminal and it’s persistent. It’s always running on the side. Then on the other side of my monitor, I would have my text editor and I’ll basically be doing my work in the text editor without interacting with the terminal at all, because the terminal is just going to rerun the tests every time I make a change. I guess the design goal is very much to not to have to switch back and forth between the two windows. There’s an alternative to adding a parameter on the command-line to run a subset of the tests, which is in Mocha. There is a feature called exclusive tests. Mocha has this syntax like the BDD style syntax where it’s like describe this and then it does this and so forth. You guys familiar with that? JOE:  Yeah. AARON:  Yeah. TOBY:  So you can tell Mocha to only run a subset of the tests in your test suite if you just rewrite your describe to describe that only, or you could also tell it to run only a single test case if you rewrite it to it.only. Then the reason this is nice is you never have to leave your text editor to make that test subset change. You can just turn on and off that only all from your text editor without going back to the terminal. So this is the workflow that I like. JOE:  Yeah, we hate that workflow because people keep checking that in. [Laughter] TOBY:  Yeah, I totally understand that. I protect against that by using a Git hook before you commit. So you’re not allowed to commit if you have that in your code. JOE:  That’s nice. CHUCK:  Yeah, I’ve used that same trick, except I usually put a comment in that’s like, “No commit,” or something and then if that’s in there, it’ll stop you from committing and say, “You’ve got this on this line.” Then if you make that change, you put that comment in. and then when you need to take it out, it’ll remind you. JOE:  That’s a very common workflow to just have the command-line running and just watching your files and then rerunning all your suite of tests. Around here, we have around six or seven hundred unit tests, so it takes us around six or seven seconds typically to execute and run. But the problem with that method is, and we use Karma not Testem, one you do get notified within six or seven seconds whether your test fails, but if you’re going to do things like trying to figure out why your test is failing, “Okay, I’ve got a failing test. I want to figure out why that test is failing and I’m not really 100% sure what I did. I might need to either do some debugging or I want to maybe before I bother all the way to debugging I just want to log out a couple of things.” Karma’s pretty bad about how it shows basically logging things out with the console. Maybe Testem might be better, but I assume it still has the same issue. If you log something out with the console in the browser, you can explore around in that object and dig down into it and see it, whereas a command-line, you don’t have any real interactivity. Plus, if you’re going to rerun all 600 tests as you’re just trying to diagnose why one test is failing, then that can be painful just waiting even just seven seconds, because, “I think I fixed it. I click save. Now I wait seven seconds to find out whether or not that test failed or not.” Actually, a guy here contributed to Karma to try to get Karma to pass through grep filters into Mocha, because Mocha has its grep option, which is sadly the only thing that we have on for client-side. We go to server-side testing framework and they actually have real test sessions where you can choose a subset of tests and then make that your session. Also, just very quickly through UI say, “Oh, I want to run just this one test.” TOBY:  Yeah, I would still recommend you try the .only trick, because that’s been working very well for me. If I need to debug a one single test, the first thing I would do is just say it.only. So it would only run that one single test. That makes the test feedback immediate. That’s first, most important thing. You’re going to get subsecond feedback, basically, if you run only one test. But the second thing is it isolates. It makes sure no other tests are affecting the outcome of this test, just in case. But also, any log output that you put in there, you know are coming from this one test. So you can put console.log statements anywhere you want. It’s coming as a result of the code in this one test. That’s very nice. Debugging is very nice there. I know with Karma, they ship a modified version of Jasmine that also has this exclusive feature. I know the Karma guys, they’re also big fans of this approach, this exclusive test. But in Karma, they call it ddescribe and iit instead of the .only syntax. Console logging. Yeah, you had a comment about console logging, right? JOE:  Right. TOBY:  I think it’s fairly, once you isolate like this, once you isolate down to one test then console logging will help a lot more, because it’s all coming from the same place. AARON:  I’m very familiar with Karma, but what is Testem’s output look like. Say I log out an object. Does it actually explore the object graph and print it all out? Karma basically just gives me an open and close curly brace just to say, “Hey that was an object.” [Laughter] TOBY:  Okay, I gotcha. In Testem, it basically tries to jsonify the object. If that doesn’t work, then it’ll fall back to string. AARON:  Gotcha. What about actual debugging. When you’re developing and you still can’t figure out why the test is failing through some console logging and you really have just got to walk through the code. I assume while Testem is running, the browsers that it’s running against are also up and available and you can go into there and open up the developer tools and put in breakpoints. But Karma has a weakness. You have to go to the debug page with Karma to fix this, but it actually delivers a time-stamped version of the file, because it’s watching the files. If you set a breakpoint and then you change that file, the breakpoint disappears. You have to go over to the little debug button. You click over to get a version that doesn’t do that. How does that work with Testem if I want to actually debug and set breakpoints and have those breakpoints held in between as I change that same file? TOBY:  I see. Okay. I’d normally try to stay away from using breakpoint debugging just because, again, I prefer to always stay in the text editor, because that’s when the workflow is fastest. But once in a while, I do want to use the debugger in Chrome or something. In that case, I’m going to actually use the debugger statement in my source code rather than going into the browser and clicking on the gutter. AARON:  I assume you have another Git hook for that? TOBY:  Correct. Yeah, I use Git hook to eliminate debugger statements, console.log statements and the .only statements from my tests. AARON:  The browsers support conditional breakpoints, depending on the browser and the development tools and stuff. Debugger is a little bit more stuck. It’s a bigger pain if you do it inside of a loop. TOBY:  Yeah, but you can always use the if statement, right? AARON:  Gotcha. TOBY:  That’s what I do sometimes, actually. AARON:  Just write in a little if statement around it. TOBY:  Yeah, when you’re debugging. So I’m debugging a problem. Again, I’m isolating it down to one test, so all the stuff, all the mess I make is only going to be within the context of this one test. I will make a big mess. I don’t care, if I’m debugging. I’ll say if the client id is 55, then I will put a debugger statement or something like that. Because at the end, when I solve the issue, I’m just going to remove all that junk. CHUCK:  I’ve got another question for you. A lot of times, I have stuff written in CoffeeScript or I want things minified. In fact, last night I was at a Ruby meet up and we were actually talking about JavaScript front-end systems and they were running into issues when they minified AngularJS. So I would like to be able to test my code as I’ve written it and then the code after it’s minified and uglified and all that stuff. Are there ways to do that so that it can test both before and after? TOBY:  Yeah, you can setup, I’m trying to think, probably the easiest way to do that is just to make two different Testem configuration files at this moment. So you would make one, and Testem has these hooks to allow you to compile anything that needs to be compiled in order for tests to run. You can make one that’s for development and then make another one that’s for production, sort of, or another one that minifies and everything. CHUCK:  Nice. So you just create two files and then you say, “Okay, run the development one. Okay, everything seems happy there. Run the production one before I go and push it out to the world.” TOBY:  Yeah. If I were to do that, I would probably only run the production one in the CI server or something. So I don’t have to do that myself manually. CHUCK:  That makes sense. And then it can do all the compilation and what-have-you’s that I need to do. TOBY:  Yeah. CHUCK:  Awesome. JOE:  We were wondering if you might give us a comparison between Testem and Karma. AARON:  Yeah, the benefits and the drawbacks. And then it would be cool, part two, you have to say one nice thing about Karma. JOE:  Oh yeah, there you go. [Laughter] TOBY:  Okay. AARON:  But it’s true that this tool is really analogous to Karma, right? TOBY:  Yeah. Definitely, yeah. I won’t have any trouble saying nice things about Karma. Those are awesome guys. They’re also the people who built AngularJS. And AngularJS is all about testing, easy testing out of the box, stuff like that. I think Testem and Karma, they had the same motivation initially, which was a JSTestDriver. People were trying to use JSTestDriver before that. It’s hard to use and also buggy. It seems like it hadn’t been well-maintained, or the author just trailed off and didn’t want to take care of the issues. I think we both built our tools motivated by that. We wanted to build a better JSTestDriver. In terms of comparing the two, I actually haven’t used Karma extensively. But what it has that Testem doesn’t is it has a pretty good integration with WebStorm I think. Even to the debugger level, from what I’ve seen. That’s definitely something that Testem doesn’t, and I don’t plan on doing something like that. Testem, I think has a nicer UI, but that might be subjective. I want to be a UI person but not really. I think about UI and UI design. That’s more important to me, in my opinion. AARON:  Yeah, I agree. I like the Testem UI better. TOBY:  But aside from that, there’s definitely tons of overlap. I think if you want to choose between the two, just use both and then make a choice. And look at the community activity around each one. I think right now, Karma has more community activity around it right now, definitely. CHUCK:  It looks like they’re both pretty easy to set up. You’re only out a little bit of time to figure out which one looks like it’s going to be a better fit for your setup. TOBY:  Yeah, I agree. They’re both designed to be easy to use out of the box, definitely. CHUCK:  So I guess my next question is, when you’re testing your JavaScript, what do you use? Do you use Mocha or do you use any of these other ones? Jasmine or QUnit or BusterJS or whatever? TOBY:  I’ve used several of them. I used to use Jasmine for the most part. I recently switched over to Mocha, I guess mainly because of the .only feature, which I like. We’re actually trying to get that feature into Jasmine, but it has not been well-received so far. We’re still trying. There’s a fork of that, trying to add .only support to Jasmine. But I’ve used QUnit for some other stuff, some different stuff. With Mocha, I guess it’s much more of a smaller framework than Jasmine. It doesn’t try to do everything. Usually, people will get an assertion library like Chai to do their assertions. And then they might get a testable library like Sinon to do their mocking and stubbing and things like that. CHUCK:  Right. Which one do you prefer, though? If you’re starting a new JavaScript project, what do you reach for? TOBY:  Currently, I’ve been happy with Mocha. I actually went away from the BDD syntax. I’ve done the BDD syntax for a long time but I recently went away from it. Now I use a more lean syntax. It’s very much like the QUnit syntax where it’s just test something, test something. CHUCK:  Gotcha. And then which browsers do you usually go with on this kind of thing? TOBY:  Either Chrome or PhantomJS, when I’m doing development. Chrome is definitely the best when it comes to you need to do debugging and things like that. CHUCK:  Did you run into any hiccups implementing any of these browsers, watchers? TOBY:  Oh yeah, definitely. It’s tricky. Ideally, you want to set up a fresh user profile for the browser so that it’s not remembering your sessions from when you were actually using the browser to browse and stuff. That gets tricky. Opera, actually recently has broken that feature. I don’t know why. And I don’t know how to fix that yet. Sometimes, it can change from when the browser upgrades and stuff like that. Then I might have to get on top of those changes and things like that. That can be hard sometimes. JOE:  I was curious about being able to set up multiple different configurations of Testem. Say you’ve got a development version so you’ve got your development configuration, then you’ve got your more production oriented configuration, maybe you’ve got a couple of those. One for a quick CI and one for your full we’re going to run more stuff. Of all those different configurations, maybe a lot of the configuration is actually shared between those three different scenarios. Is there a way to share the configuration and have one file that has all the common ones, pieces of configuration, and other files that have just the overrides with Testem? TOBY:  No, not at the moment. At the moment, it’s pretty limited. The configuration is pretty limited [in] regards to that, but I would like to make that better in the future. CHUCK:  Your configuration files are JSON files, right? TOBY:  Yeah, correct. They can either be JSON or YAML. CHUCK:  So you could conceivably put some little thing in there that just builds them out, so if you change the base file it, I don’t know. TOBY:  Yeah. That would be a good feature to add, for sure. CHUCK:  Like do a Grunt task or something. I don’t know. JOE:  Yeah, I was going to say Grunt would be easy to do this stuff with. TOBY:  Yeah. AARON:  Tell me, who are some of your main contributors that you want to give a shout-out to? Who helps out a lot in the community? TOBY:  There’s Raynos, real name is Jake. He is one of my first enthusiastic users and he gave me a lot of feedback and a lot of pull requests. He’s also the one that pushed me toward making it work with Node.js  tests instead of just the browser. Give a shout-out to Jake. And Derek Brans helped me a lot with the BrowserStack integration. BrowserStack integration, in my opinion, is really a huge feature. You can basically, in CI mode, I currently have my tests running on all these different browsers that are hosted in the cloud. BrowserStack has a huge menu of different browsers and different versions of those browsers that you can choose from. It’s amazing, if you think about it, that you can choose whatever browsers you want and then just say run the test and it’ll do it on all of them. JOE:  That’s awesome. AARON:  Yeah, that’s great. So another question, we were wondering. A lot of us, when we’re developing for the front-end, we use a lot of Grunt watch tasks. And it sounds like Testem runs on its own. Do you prefer to avoid Grunt when you’re working with your tests? How do you integrate with Grunt or what are your recommendations with Grunt? Grunt’s gotten so big. What are your thoughts around Grunt? TOBY:  I personally don’t actually use Grunt, so I guess I’m not a good person to ask that question. I do agree Grunt has gotten big. It’s got a lot of features and it seems like there’s a lot of potential integration points. But I just don’t know those very well. Somebody that knows more about Grunt can help out there. JOE:  I assume nobody’s written a prebuilt Grunt task for Testem? TOBY:  There is one, actually. I assume it’s just, you configure it. You configure Testem within Grunt and then it’ll just run it. Oh, I also want to give a shout-out to Justin Searls and Dave Mosher. They have also been very supportive in initially getting the word out about Testem and using it a lot. They also built this scaffolding, app scaffolding tool, called lineman for bootstrapping your web apps, things like that, which uses Testem for its testing features. I actually would like to ask you guys. How do you guys approach testing in your work? JOE:  We practice the TATFT system. [Laughter] CHUCK:  I’ve got to put a link to that in the show notes, too. JOE:  Yeah, you have to link that out. I won’t repeat what it means, what it stands for, on the air. CHUCK:  Clean podcast. JOE:  Yeah, clean podcast. So I can speak to what Aaron and I do here at Domo. We do a significant amount of unit tests. We have a fair number of people who do tests after and then a few, probably maybe a third of us who do test-first development. We add a lot of unit tests. We happen to be using Karma to execute the unit tests here, but we also are executing our unit tests just using the browsers, like Mocha’s html test runner file. We do that a fair amount for debugging. We’re maybe slowly migrating away to using just the Karma and then doing more like, I know people have talked about the Git hook stuff that you were talking about. It seems like that actually might give us a little bit more [naveling] for that. Then we also have some other groups. Our QA groups write UI tests and we write a small number of integration tests. But mostly we just do unit tests around here. We just run those a lot. AARON:  Yeah, we let our QA team take on the integration stuff. They use a Ruby-based framework as well. JOE:  Does that answer your question? TOBY:  Do you find, TDD, do you run into any trouble around what kind of test to write or how to be more productive? In TDD, it’s a little bit tricky sometimes to get it right, in my opinion. I work with some programmers who are newer to TDD and I find one thing they do is they would over-test. They would either write too many tests or assert too many things, or they’re using mocks too much. That could become wasted effort after a while. JOE:  Yeah, I’m a really hardcore TDDer. When I came over here at Domo, I’ve been working really hard to get more and more people to use TDD. Then we recently hired some people that are more TDD fans. Aaron is and Dave Geddes, that I mentioned. But I definitely find that there are a couple of hard places when writing TDD, especially in JavaScript. Anything that interacts with the UI, it’s hard to TDD that. It’s also oftentimes hard to understand enough about the code to write TDD in any way. I usually practice a system where I’ll spike it out and write the code and figure out how it’s supposed to write, and then I’ll throw all that away and start over with TDD once I get an idea. So I can still let the TDD actually shape my code. TOBY:  That’s a great approach. JOE:  Yeah. The value of TDD is not the fact that you have tests when you’re done, but that it helps you write better code. The tests when you’re done is just a by-product and a nice side-effect. But I want it to help me shape my code. So if I don’t understand enough about the code that I need to spike it out, then I’ll just spike it out and come back. Yeah, we see a lot of those. We just practice sort of an 80/20 rule around here. We get to some places where it’s really hard to test a particular piece or the test becomes really brutal because unit tests oftentimes we just skip and not unit test that piece and not spend a huge amount of cost for the benefit. But if we find ourselves doing that a lot, then that’s pretty much an indication that our code is just too hard to test overall. We’ve got to rethink something. CHUCK:  The approach that you guys are talking about is more or less what I do. Typically, I’m testing a lot more Ruby than I’m testing JavaScript. I have to admit that I should test my JavaScript more than I do. JOE:  Yes you should. CHUCK:  However, I typically go with doing mainly unit tests. I do some integration tests, but it’s usually only on critical path stuff. For example, I worked on an application and I’m going to dance around the details because I’m under NDA, but they had a pretty hairy application process for it where you would apply to the program. It was a critical path thing. It was a mess. So we put some integration tests around it so that we could just run that and make sure that it worked instead of manually testing it all the time. That saved us a bunch of time and it also provided us with a sanity check on something that was both complicated and important. But I don’t do that very often at all. We just use Selenium to run those tests. Like I said, it worked out pretty well for us, but the other aspects of the application, we definitely didn’t integration test them because they just weren’t as important. But that one piece was critical to the app and critical to the profitability for the client, so that’s what we did. AARON:  I think that’s a great approach to look at those things and if it’s too tough, you’re spending too much time, just hit those things from an integration level, in the browser with Selenium or a different library. I think that’s a great approach. I really like that approach. JOE:  Another thing that we find ourselves, the way we handle that when we find code that’s just really hard to test, is to try to minimize the quantity of that code by moving the business logic into a separate class that’s actually just a plain JavaScript class for example and make that easy to test. Then make the other class that’s really hard to test. For example, directives can be hard to test sometimes. There are issues with, in Angular I’m speaking, issues with having an external template. You have to use Karma for the external template. There’s no scene if you have a directive that aggregates another directive. There’s no scene between the two directives so that you can mock out the interior aggregated directive. Or if a directive has a controller, you can’t mock the controller. Sometimes, those things can make directives difficult to test. You can manage that by just moving more code into the controller and just testing, since it’s just a plain controller, it’s easy to test. Or moving code into a service. Even though it makes the class, sometime something can seem a little funny because you’re like, “Shouldn’t’ that logic just be here in that class?” But if the class is hard to test, then I’m a strong proponent of moving the code somewhere where it’s just easier to test and then just putting a tighter coupling between the class that’s hard to test and the class that isn’t’. TOBY:  That is interesting, too. JOE:  Because I’d much rather have the code tested, the logic tested, and then just worry about, okay, I look at this code and I see that it integrates with this so it just has to make some calls and pass values back and forth. That’s a lot easier to look and see if you got something wrong with a glance and do it by hand than it is to understand, hey I’ve got complex business logic with a bunch of branches and is this working right or not, versus it practically almost becomes configuration. Your [inaudible] class, it’s hard to test. It’s mostly configuration saying I’m passing these calls into something else and that’s easy to tell that you did or didn’t output that. It just becomes less risky code. It’s less likely that code’s going to break in the future. If you have tests around it, then you’re mitigating the risk. CHUCK:  Alright. Well are there any other aspects of Testem that we haven’t talked through you want to go over? AARON:  I will say that we found a solid Grunt plugin for it, so yeah, that’s definitely there. CHUCK:  Oh, nice. You want to put a link in the chat so we have it in the show notes? AARON:  Yeah, we’ll link it. CHUCK:  Awesome. Alright, well let’s go ahead and do the picks then. Joe, you want to start us off? JOE:  You bet. I’ve only got one pick this week and that is the book The Rithmatist by Bandon Sanderson. Not arithmetist, but just rithmetist. It’s called The Rithmatist. It’s very Harry Potter-ish, but I just absolutely loved it. I zipped through it in just a few days. I really couldn’t put it down. I thought it was just a fantastic book. I enjoyed reading it every bit as much as enjoyed reading Harry Potter. And the world that he created, I think is just amazing. Brandon Sanderson’s an absolute genius. I’m going to pick that book for my pick this week. AARON:  He’s crying, everyone. [Laughter] JOE:  I am. There are tears streaming. AARON:  His eyes watered up. JOE:  Streaming down my face. AARON:  Yeah. CHUCK:  There we go. Alright. Aaron, what are your picks? AARON:  Man, I’m going to have one. I didn’t know of this picks thing. I didn’t even get prepared for that. I do a lot of coding late at night and I do a lot authoring late at night, a lot of work after the kids are in bed and my wife and I have had time to chat for a bit. So when I wind down, sometimes when it’s that late, I’ve got to concentrate again for a second, so I’m going to do, click on Call of Duty: Black Ops 2, because that helps me stretch my legs and get back into it in a few minutes. So that’s my pick, is Call of Duty: Black Ops 2. JOE:  I love it. Great pick. CHUCK:  Nice. Alright, I’ve got a couple of picks here. The first one is, a little bit of background, my laptop now (you’re all going to laugh), but it’s a white MacBook 2009, so it’s an old machine. I upgraded it as much as I could as far as hard drive and memory went, but I’ve been getting an hour’s battery out of it, which makes me unhappy. It was better before, but it’s just the nature of a machine that’s four years old. JOE: Wait a second, can’t you just pop out that battery and put a new one in? CHUCK:  That’s what I’m doing. I actually went on Amazon and I searched for MacBook battery 2009, and I guess they originally were $100 or something. I guess not a lot of people are buying old batteries for old MacBooks so I got mine for $20. So my first pick is Amazon Prime, because I’m getting it in two days. So life will be infinitely better, I’m hoping. JOE:  Does the battery come with the videos that instruct you on how to get a well torch out and pull the case apart and replace? It’s a four-hour job to replace the battery, right? CHUCK:  No. You push the button and it comes out and then you pop the new one in. JOE:  Oh, that’s not the Mac I’m thinking of then. Are you sure it was a Mac? Maybe you’re talking about a PC. [Laughter] AARON:  Oh, geez. [Laughter] CHUCK:  Why do I feel like I’m being trolled? JOE:  Because you are. As I sit here on my Mac. AARON:  That’s going into the clips at the beginning. JOE:  That’s right. [Laughter] CHUCK:  Yeah. So super nice. It was funny, because I was talking to my assistant and she’s looking for something to solve the same problem on her even older MacBook Pro. I guess she was having trouble identifying which battery to but, or I’m not even sure. But there are external batteries that go with them. The cheapest one I found was still $150. I figured $20 is a little bit more palatable before I get around to buying a new machine. Anyway, love Amazon and love Amazon Prime. So if you’re not on Amazon Prime then go check it out. The other picks that I have, I started watching The Big Bang Theory. Yes I know. I’m behind the times. But oh my gosh, I watched two or three episodes last night and they were hilarious. Anyway, I’m really enjoying that so I’m going to pick that. Finally, I’m also going to pick HandBrake. If you have videos that are not mp4s, you can’t play them on your Apple devices like your iPad, which is what I wanted to watch those particular videos on. So I used HandBrake to convert them to mp4 and it works terrific. So those are my picks. Toby, what are your picks? TOBY:  I want to pick a talk by Sandi Metz. It’s called, I think, The Magic Tricks of Testing. It’s just got great practical advice about unit testing and what kind of test to write and what kind of test not to write. CHUCK:  Nice. TOBY:  And I also have one, it’s called the Secrets of Superstar Programmer Productivity by Giles Bowkett. He talks about the concept of flow, from a book of the same title. It’s called Flow: the psychology of optimal experience. Basically, the more you can concentrate and not be interrupted, the more productive you’re going to be. I’m going to [inaudible] the links into the chat. CHUCK:  Awesome. Well thanks for coming, Toby. It was a terrific discussion and definitely a tool that I’m going to be looking at here. TOBY:  Thank you for having me. It was a pleasure. CHUCK:  No problem. So we’ll go ahead. AARON:  Thanks for letting me be on too, though. This was fun. CHUCK:  Yeah. Maybe we’ll have you back. AARON:  Yeah. CHUCK:  Alright, well let’s go ahead and wrap up the show. Once again, thank you for listening. Before we wrap up, I do want to mention our book club book. We’re reading, and I know I’m going to say this wrong, JavaScript Allongé by Reg Braithwaite and we’re going to be reading that in a few weeks. I don’t have the exact date in front of me. So we’ll put that in the show notes so that you know. We look forward to reading the book. Catch you all next week.

x