Panel
 Jörn Zaefferer (twitter github blog)
 Jamison Dance (twitter github blog)
 Joe Eames (twitter github blog)
 Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up)
 Discussion
 01:15 - Jörn Zaefferer Introduction

jQuery
QUnit

02:32 - QUnit

jQuery Mobile
Introduction to Unit Testing | QUnit

06:59 - Built-in support for HTML fixtures for your tests

08:50 - Unit Testing

joshuaclayton / specit

mmonteleone / pavlov

11:57 - Assertions

fn:deep-equal

15:49 - Why use QUnit?

unit testing - QUnit vs Jasmine - Stack Overflow

stacktrace.js

023 RR Book Club: Smalltalk Best Practice Patterns with Kent Beck

26:01 - User experience for user interface

30:03 - Continuous integration setups

Jenkins CI 
PhantomJS 
023 JSJ Phantom.js with Ariya Hidayat 

jquery / testswarm

jQuery's TestSwarm

BrowserStack 

36:55 - Testing in JavaScript

Sauce Labs: Cloudified Browser Testing 
Testacular 
SeleniumHQ 

43:35 - Add-ons

Picks

MYO - The Gesture Control Armband (Jamison)
Mailbox (Jamison)
Testing Clientside JavaScript (Joe’s Course) (Joe)
DragonBox (Joe)
Breeze.js (Joe)
Anker Battery Pack (Chuck)
App.net (Chuck)
Leap Motion (Jörn)
jQuery Validation Plugin Pledgie (Jörn)

Next Week
 Finding a job
 Transcript
 JOE:  I'm really glad that I didn’t know you when Star Wars first came out....Dude! Vader’s Luke’s father.

[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.]

CHUCK:  Hey everybody and welcome to Episode 50 of the JavaScript Jabber Show. This week on our panel, we have Jamison Dance.

JAMISON:  Hello friends.

CHUCK:  We have Joe Eames.

JOE:  Hey, everybody.

CHUCK:  I'm Charles Max Wood from DevChat.tv. I'm the only person on this particular episode whose name does not start with J.

We also have -- I know I'm going to destroy this name. Jorn Zaefferer.

JORN:  Hi! Yeah, it’s me. You should have practiced the last name too.

CHUCK:  Yeah.

JOE:  You should pronounce that correctly for us so we know.

JORN:  Jorn Zaefferer.

CHUCK:  Alright. Well, I can say Jorn. So, I’m going to stick with that.

JORN:  Yeah, that works.

CHUCK:  Do you want to introduce your self for the people who aren’t aware of who you are and what you do?

JORN:  Sure. I'm a freelance software developer since a little bit more than two years now. I am involved a lot in the jQuery project and have been involved in that for years. So far, I'm the only person on the Board of Directors of the jQuery Foundation outside of the US. And for the jQuery project, I'm working mostly on jQuery UI and the testing tools. So jQuery UI, I'm one of the lead developers. One was Scott Gonzalez. For the testing tools, I'm leading that team. So, I'm trying to get contributions from other people so things move along evenly. There’s usually much more work to do than I can handle myself. So, I’m trying my best to get open source going there.

CHUCK:  So, you work on jQuery UI and QUnit?

JORN:  I’m working on the jQuery UI and the testing tools which involves QUnit and a few other things. QUnit is the one that’s actually featured in the jQuery site. We also have TestSwarm and even smaller tools that eventually should get there as well. It’s much more influx than QUnit is.

CHUCK:  Interesting. So, we brought you on the show to talk about QUnit. Joe is kind of our testing guru as far as JavaScript goes. Is QUnit just a unit testing framework or do you provide other tools for integration with a backend or other libraries?

JORN:  QUnit focuses mostly on unit testing. But people usually end up using it for other things as well. I heard a story where someone was using QUnit to do performance regression testing.

Special Guest: Jörn Zaefferer.

 

I'm really glad that I didn’t know you when Star Wars first came out....Dude! Vader’s Luke’s father. 

 

[Hosting and bandwidth provided by the Blue Box Group. Check them out atBluebox.net.] 

 

[This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go toWijmo.com and check them out.] 

 

CHUCK: Hey everybody and welcome to Episode 50 of the JavaScript Jabber Show. This week on our panel, we have Jamison Dance. 

 

JAMISON: Hello friends. 

 

CHUCK: We have Joe Eames. 

 

JOE: Hey, everybody. 

 

CHUCK: I'm Charles Max Wood from DevChat.tv. I'm the only person on this particular episode whose name does not start with J. We also have -- I know I'm going to destroy this name. Jorn Zaefferer. 

 

JORN: Hi! Yeah, it’s me. You should have practiced the last name too. 

 

CHUCK: Yeah. 

 

JOE: You should pronounce that correctly for us so we know. 

 

JORN: Jorn Zaefferer. 

 

CHUCK: Alright. Well, I can say Jorn. So, I’m going to stick with that. 

 

JORN: Yeah, that works. 

 

CHUCK: Do you want to introduce your self for the people who aren’t aware of who you are and what you do? 

 

JORN: Sure. I'm a freelance software developer since a little bit more than two years now. I am involved a lot in the jQuery project and have been involved in that for years. So far, I'm the only person on the Board of Directors of the jQuery Foundation outside of the US. And for the jQuery project, I'm working mostly on jQuery UI and the testing tools. So jQuery UI, I'm one of the lead developers. One was Scott Gonzalez. For the testing tools, I'm leading that team. So, I'm trying to get contributions from other people so things move along evenly. There’s usually much more work to do than I can handle myself. So, I’m trying my best to get open source going there.

 

CHUCK: So, you work on jQuery UI and QUnit? 

 

JORN: I’m working on the jQuery UI and the testing tools which involves QUnit and a few other things. QUnit is the one that’s actually featured in the jQuery site. We also have TestSwarm and even smaller tools that eventually should get there as well. It’s much more influx than QUnit is. 

 

CHUCK: Interesting. So, we brought you on the show to talk about QUnit. Joe is kind of our testing guru as far as JavaScript goes. Is QUnit just a unit testing framework or do you provide other tools for integration with a backend or other libraries? 

 

JORN: QUnit focuses mostly on unit testing. But people usually end up using it for other things as well. I heard a story where someone was using QUnit to do performance regression testing. So, you can do that with QUnit. It’s pretty customizable if you want to, but the focus is pretty much on testing JavaScript libraries within the browser. 

 

CHUCK: So, it’s mostly browser-based? 

 

JORN: Yes. That's the focus and that’s basically all the new features and improvements go to. For example, within Node.js there are a lot of alternatives which made more sense within Node. So, that's not something that we focus on. 

 

CHUCK: Okay. So QUnit, before the show, and before the intro when you give us a little bit longer explanation that I'm going to ask you for in a minute, all I really knew about QUnit's origin was that it came out of jQuery one way or the other. Do you want to explain where QUnit came from? 

 

JORN: Sure. QUnit, the code base was originally written by John Resig as part of starting jQuery itself in 2006. He figured that unit testing is useful especially for a complex library like jQuery where having automatic tests that can just run in multiple browsers is pretty useful. In early 2006 when I got involved in jQuery, my first contribution was actually to write more tests because the coverage was like 2% or something. Later, I worked on the Ajax module in jQuery. It was like the second half of 2006. And I extended a test runner there to actually make basing testing possible. Originally, it didn't support that. 

 

JAMISON: How recent was that? Oh, you're still talking about the internal jQuery stuff before QUnit. 

 

JORN: This was before QUnit actually existed. So, there was just a code base. And then in 2008, I suggested that John actually make this a stand alone project and then gave it the name QUnit. Was like the Q from jQuery and the Unit from JUnit. I rewrote the documentation to just document the API and we move the code around inside the sub-version of prodigy that we were using back then so that other projects could start using it. JQuery UI already existed then, we used it there. Text removal later started using it and other people could start using it. That wasn’t really promoted anywhere on the jQuery site, it was just a page on the wiki. A little later, I think 2009, John did the rewrite to actually make QUnit independent of jQuery. Originally QUnit itself was using jQuery to do all the DOM stuff. We got rid of that dependency which means there's no more DOM handling stuff inside QUnit but it doesn't do that much, so it's still pretty sane. Pretty much since I gave it the name, I also kept maintaining QUnit. Since last year, we actually now have up our proper website at QUnitJS.com and nice API documentation and tutorials and stuff. There’s actually one chapter from the jQuery cookbook that I originally wrote for the book with Scott Gonzalez. And that's now as a page on the QUnit website. 

 

CHUCK: Nice. 

 

JORN: It’s a really good introduction if you're getting started with QUnit. 

 

JOE: My favorite part of this podcast today is finding out why you named it QUnit. [Laughter] 

 

JAMISON: The podcast has only just begun. There's plenty of time for my favorite parts. [Laughter] 

 

JORN: That's pretty much the story around the name. You already pronounce it correctly. Sometimes, people say quenit. But that's not right. 

 

CHUCK: Yeah. Since it came out of jQuery, I was thinking JQuenit or something. [Laughter] 

 

JAMISON: So, I haven't used QUnit in a project but I have gone looking over the documentation a little bit just to prepare for this. And one thing that seems interesting that isn't as common or as easily accessible in other frameworks is it looks like QUnit has built-in support for actual HTML fixtures for your tests. Am I correct about that? 

 

JORN: Yes, that's actually a pretty useful feature of QUnit. The idea is that, let’s say you're writing a jQuery plug-in that works on some amount of existing markup. For example, jQuery UI widgets, let’s say the auto-complete, you start with an input element and that's it. You would just put an input into the QUnit fixture, which is just an element with the ID QUnit-fixture and then QUnit will take care of resetting that markup or that element after each test. So in each test, you can start with that same element and don’t have to worry about providing the markup. 

 

JAMISON: So, you provide the markup in your test and it goes to that QUnit fixture div and then it’s wiped out between every test? 

 

JOE: It's not quite inside the test. It's inside the HTML page that runs your test. 

 

JORN: Yeah, that's a better description. So, you can either have markup in there inside the HTML file, or each test can just put something into that element and you don't have to worry about removing it later because that's what QUnit test will do. But it's not a requirement. If you leave out that element in your HTML file, then QUnit won't bother with it and just you have to provide, if you actually have markup that you test against, you just have to provide that yourself. 

 

CHUCK: One thing that I've noticed is that in a lot of cases, in a lot of the languages that I deal with, there seem to be two kinds of schools of thought around unit testing and testing in general. And so, there are usually libraries that take one approach or the other. So, QUnit, like JUnit and some of these others, takes the approach of giving you an assertion. So, you have the equal assertion and you give it the expected value and the actual value and an error message and then, it will put up the error message and tell you that the assertion failed if it doesn't match. And then, you have the other way of looking at things like Jasmine where you have some kind of thing where it’s like expecttrue.tobe whatever. Do you see any major advantages to using the assertions as opposed to the expectations? 

 

JORN: Both styles are valid. Some people prefer the one or the other. There are actually two add-ons for QUnit which basically wrap QUnit and give you this behavior-driven style. I think we have show notes so we can provide links to those. They're also on the QUnit website under add-ons. So, specit and povlov both provide BDD style testing APIs on top of QUnit. So far, enough people like QUnit just the way it is, myself included. Enough people like the BDD style, either they use some of the adjustment or use one of the add-ons and still have the underlying QUnit. So, I didn't have strong opinions about those. I prefer the simple set style that JUnit had. Sometimes people complain about that. If you use, for example, jQuery’s equal method, then you have to remember that the actual argument comes first, and the expected argument comes second. Like with the BDD style, the APIs suggest which one is which, you don't have to remember the order. This is, like you look it up once you remember it and if you forget it, look it up again. Then, you’d probably remembered and that's it. It’s not something that you actually have to bother with more than twice. 

 

JOE: My problem with that is that if I use a server side one that does it the opposite way, then it's hard when you're going back and forth on a single project. I've got caught by that a bunch of times. JORN: Yeah. That can be annoying. 

 

CHUCK: That's why you use Rails on the backend. [Laughter] 

 

JOE: Good idea. 

 

JORN: But I think if you take all these search libraries from different frameworks, there's no consensus of which order the arguments should be. Usually, like John was saying, “Let's make the methods in a way where the order doesn't matter because you say expect this to be that and it’s a little ambiguous. 

 

CHUCK: So, one thing that I want to point out here because I got in here and I realize that there are few of these assertions that I really, really like, that I don't have in some of the other tools that I use. For example, the Deep Equal, that's cool. 

 

JORN: Yeah, Deep Equal is pretty useful. It allows you to pass in any objects and it will try to figure out if there's anything inside that object that doesn't match. So, it doesn't just compare the identity like the regular equal or strict equal will do. It actually looks inside the object. And this is something that originally someone, I think his name is Philip, contributed and there's some pretty big test feeds attached to that. So, QUnit actually uses QUnit itself to test a lot of its own features. And the Deep Equal unit tests are pretty extensive. They cover like [inaudible] where one object points to itself and compares functions and regular expressions and dates and whatnot. It's really useful to just compare the objects where you just don't want to have just one line for each property that you care about. 

 

CHUCK: So, I guess that's one question that I have is, if you have two objects that effectively define the same function but don't use the same reference to the same function, do they match on deep equal? 

 

JORN: I'm not exactly sure what function. I don't have the implementation memorized for these details. 

 

JOE: What?! Ohhh! [Laughter] 

 

CHUCK: Well, it would be interesting to know. I’ll just go check it out myself. One other thing I want to point out on the QUnit site that I really, really, really liked. You have an intro to unit testing. And the thing that I like most about this is not actually telling people how to write unit tests. It's the fact that you make it -- there are like three or four refactoring stages through the tutorial. No, I guess there are just two. But you re-factor it down to the point where it’s easier to manage, it's easier to think about, and easier to test. It really kind of pushes people to think about that as they work through their examples and make sure that they match up with what's there. I was really, really impressed with that. 

 

JORN: Yes. That's actually on an article I wrote for Smashing Magazine and they agreed to a non-exclusive license so that I could later publish that article in the QUnit site. This idea started when I was actually sitting next to someone who was asking me about QUnit and the code he had was just embedded into the page. I think it was pretty close to the example that the article uses. I figured like explaining how to refactor your code to make it unit testable would be really useful for a lot of other people. So, the code samples are somewhat convoluted but I think the example itself is still really pretty nice. Just to give you the idea that you can get started with the QUnit testing which is not so much about learning the framework but just bring out how to actually make your code unit testable and refactoring is a big part of that. 

 

CHUCK: Yeah. I'm not going to pick it for this show because we're talking about it. But I'm probably going to wind up picking it for Ruby Rogues and stuff, just because I love the way that this is put together. It’s self-explanatory and it really does drive home -look, it makes the code better, it makes it easier to manage and understand, you get test around it, you know that it works. I mean, there are just huge, huge benefits to this way of approaching a programming problem. 

 

JOE: Yeah, totally. 

 

JAMISON: So, I have a question. Testing frameworks in JavaScript are proliferating, and there's more every day. And it seems like every time someone runs into a hiccup with the testing framework, they think the best solution is to write their own. So, there's tons of them out there. Why use QUnit instead of one of the many other ones out there? 

 

JORN: So, there's actually a staggered workflow question which I want to answer that I think I'm getting a lot of staggered workflow reputation from people just uploading that. 

 

JAMISON: Trade those in for the big coins, right? [Laughter] 

 

JORN: Yeah, I think that works. So, the question was should I use QUnit or Jasmine, like those seem to be the two most popular choices. And I wrote that because one big argument for QUnit is that it’s really easy to get started with. You just take these two files from QUnit, one JS and one CSS file, you add a div with an ID of QUnit, and then write a test and that’s it. You're done. You don't need to set up any reporters, and there's nothing else you need to do. We actually recently did a survey for QUnit to figure out what people like or don't like about QUnit, what we should add or remove. The ease of use was basically the one everyone mentioned that they really liked that. Otherwise, Jasmine has the BDD style syntax if you don't want to use QUnit with the wrapper. It might be a good idea to just start with Jasmine. They certainly have other features that QUnit doesn't have. I didn’t ever really use any other frameworks. So, I'm not the best person to ask about those. There are probably other people that have more experience using a wide range of testing frameworks. I mean, both probably get the job done. If you have people already familiar with Jasmine, that might be better to get started with. One thing worth mentioning, the Ember.js team like Yehuda and Tom Dale, and whoever else is on their team, they keep telling me that they really like QUnit because it’s so freaking stable. It does exactly what they wanted to do and it does it really well. Yehuda also has the given advantage of, if he comes up with the feature request. I care about his ideas. So, if they're reasonable, then there's a good chance that they can actually make it into QUnit which generally applies to every feature request. But I guess, Yehuda has a certain advantage there. 

 

JAMISON: Yeah. It helps if you have the jQuery connections, probably. 

 

JOE: I think there's another big advantage that QUnit has over the others, and that is most of the others, certainly the ones that are pretty popular which, Jasmine for sure. And I think Mocha is gaining a lot of popularity, although Mocha is really, really flexible in this. But QUnit, by default, has the non-BDD style and that actually typically simulates what server side testing frameworks use. Most server side testing frameworks use JUnit, csUnit, the other .NET ones. Those are using the non-BDD style. 

 

CHUCK: Ruby has mini test and test unit. 

 

JOE: Right. So, it makes it more familiar. If you're not just writing JavaScript, if you're writing server side and client side code, you don't have to switch your brain context. I know there's plenty of BDD style frameworks for the server side too, but I just think the non-BDD style ones are the more common. 

 

CHUCK: The other thing that I really, that appeals to me out of QUnit is the fact that since it came out of jQuery, it's designed to work with jQuery. You know, most the other frameworks, they work fine with jQuery. But the fact that it's part of the jQuery suite of tools that are out there, it does have that where you can pretty well count on. If you're writing DOM related code, QUnit will probably test it well. 

 

JORN: Yeah, that makes sense. I don’t know of any other particular issues with other framework in that regard. Like for example, the fixture thing that we talked about, that’s very DOM focused and wouldn’t make sense on the server side. So, that might be a good reason to use QUnit. There’s actually a few other features that I hope other people will pick up and put into their own frameworks that might currently be specific to QUnit. I haven’t ever checked if someone else tested this but there’s some details inside QUnit that you don’t notice until you really use it for a long time or at least more than just a few hours. Like, QUnit tries to be as useful as possible to help you be efficient with your development. So for example, when an assertion fails without actually throwing exceptions, just something goes bad. Actually let’s just skip back a little bit. One important thing about QUnit designs is that when an assertion fails, it doesn’t actually throw an assertion error or an assertion exception like for example JUnit does that, and I think a lot of other frameworks do it. So QUnit just tries to go on. And as long as the code doesn’t actually throw an exception, it tries to run the test until the end which means that you might get more assertion that fail which doesn’t necessarily tell you more. But sometimes it’s actually useful to see all the assertions run and one of the later ones might actually give away the actual issue where the first one that failed might actually be pretty useless. So, if it just fails as soon as something goes wrong, you don’t know if everything else would actually have worked. And the thing is that as soon as something fails, QUnit tries to actually tell you exactly where that code is coming from. Even without an exception being thrown, then QUnit tries to figure out where’s the assertion that you ran in your code and tell you which line in your user code it is. If it’s like nested, if you have a test that calls a method that calls another method and those go through different files, then they actually provides you a stack trace with all those files. But because you don’t really care which lines of codes within QUnit itself run, it will actually filter those out. So, you only see your own code in the stack trace. 

 

CHUCK: That’s really nice. 

 

JORN: It doesn’t try to implement the stack trace stuff.

There’s a line we call stacktrace.js, something like that, which actually will download files and try to figure out where exactly the code is that just ran. QUnit doesn’t do that. So, in IE8, you don’t get stack traces. But pretty much any browser that does support extracting stack trace and generating them on the fly, the QUnit will make use of that. That’s one thing that makes development pretty nice because once something fails, it’s really easy to point out which lines you have to look at, like where is the assertion that failed? There’s a feature that actually required a big refactoring inside QUnit itself which, I wouldn’t say I stole it, but I get sort of the inspiration for that feature from Kent Beck who originally created JUnit with, I think, Erich Gamma on a plane. So, he once built a tool, I think it was in a plug-in for Eclipse that basically was a JUnit runner inside Eclipse. And one big idea was that, usually when a test fails, it is much more likely that it will fail again the next run. While if the test passed, it’s likely that it will pass again. So, running those failing tests first, especially if they take very little time, gives you feedback much faster. In his tool, I think he actually built something where it would show you, in your source file, where something threw an exception. So, the added integration, I think, it was a bit too much but I like the idea of running tests that failed before. So, what QUnit now does, if session storage is supported by your browser, it stores when a test fails and on the next run, runs that test first. Usually, if you see a test failing, you can just reload the page after fixing something and if it doesn’t run again, then you can now actually fix this, and you can still wait for the full suite to run to see if there’s no other regressions. But usually, it means if your test speed takes like, say a minute to run, which can happen after a few months of development, the failing test will run first and then you can get feedback much faster. And QUnit also has this checkbox at the header which says ‘Hide passed tests’ and that means, hide everything that’s green and only show failures. And if you combine that with the session storage thing, then you actually get to see the failures first and it just hides everything else. It’s very useful if you do like test driven development because it allows you to focus so much more on things that went wrong and you don’t have to bother looking at the stuff that just went green. It’s not on by default because it can be irritating if it doesn’t show any tests. But once you enable it, it remembers the checkbox and you can just reload the page and it keeps that state. 

 

CHUCK: That’s really cool. I’ve seen it more basically, it does that. It runs the failing tests or the failings test file and then once that passes, then it will run your full suite again. 

 

JAMISON: Yeah, that’s really cool. 

 

JOE: Yeah, that’s very cool. 

 

JORN: The order in which it outputs the tests is still the original one, it only reorders the run time. So, it runs the frame test first but the operate order is the same. So, it’s not distracting, so you don’t have to find your test because now the order just suddenly changed. 

 

CHUCK: Yes. I also really, really admire Kent. So, anything you can attach his name to, I’m all level about that. 

 

JOE: That brings me to a big rant I have about JavaScript unit testing frameworks in general, and all of them are guilty of this. That is the user interface, the user experience for somebody using them, I think is just terrible. Especially compare to the long running server side test frameworks where you can like, “Oh, I want to run this test and this test, and this test, and these three tests, and these five tests, and make a session out of that and just run those five.” None of them have that feature, that feature or nice ability to collapse and expand tests. The QUnit is probably the best at showing me the failing tests. In Mocha, if you say, “Show me the failing tests,” you may have 420 tests right now in a unit suite, which is nothing. And still, it takes me a ton of times going around to find a freaking failing test even if I check the code of only failing tests. 

 

JORN: Okay. So, QUnit actually has some filters. It may not be as flexible as what you’re looking for, but you can just hide all the past tests which somebody mentioned before. You can also, if you’re using a newer version of QUnit, there’s a select box at the top right that actually allows you to select the module to run. So in QUnit, you start to get tests or you put assertions into tests and then you put the tests into modules. So for example, in jQuery UI, we have a module for some option testing for testing methods, for testing events and each one of those is grouped in a module. And select a module will run only the test within that one module. You can also click the rerun link next to any test and then, it will rerun like only one test. Actually, there’s a wild card filter where you can put into the URL if the test could be put there. I think it’s QUnit-Filter or just Filter equal, and then some value and then it will only match tests that match that wild card which would allow you to match tests from various modules if that’s something that you’re looking for. Not necessarily quite as flexible as some other tools are. But if that’s something that you actually would like, then filing an issue would be a good first step. 

 

JOE: Right. 

 

CHUCK: It’s open source. You can always patch it and then hand it over, hand a patch over. 

 

JOE: Just out of curiosity, I’m pretty familiar with QUnit but when you do the filtering, when I click on a module and it just runs the test within that module, is that just doing the name match up on the name of the module? 

 

JORN: Yeah, pretty much. 

 

JOE: A string name. Yeah, so I’ve noticed this with some of the other ones. I haven’t used QUnit in production in a little while. But with the other ones that I’ve used, they do the same thing. It’s just a string match up. If you have two modules that one is basically, I’m going to call it app and the other one called app stuff, and I click on app, it will run app and app stuff because app still matches app stuff. And so, that could be another -- you know, again, it’s just those tools for the server side testing, people have been building those for a long time and they’re getting a lot more usage than they getting out of the client side. Very few people are testing client side. 

 

JORN: Yeah, that’s true. 

 

JOE: So, there’s definitely not better…there you go. 

 

JORN: It might be that QUnit actually does the strict matching on the module name because originally, we only had the filter option that would always do wild card like the UI doesn’t expose that anywhere, you can still use the define and it’s in the documentation. But the idea is mostly to actually use what the UI exposes. I can’t tell right now if it does a strict matching or not, but it probably should. 

 

CHUCK: One thing that I want to ask about was that I’ve noticed with a lot of these frameworks is that you basically embed your tests into a webpage and then you pull up the webpage and it shows you which one’s passed and which one’s failed. I’m wondering, does that integrate well with continuous integration setups? 

 

JORN: That’s a fun topic. I think I mentioned earlier this survey that we did for QUnit and some people are already using QUnit within continuous integration like Jenkins and other tools. Other people would like to use it but don’t know how and didn’t want to spend the time to figure it out. So, there are various options already, like all the jQuery projects use Jenkins along, to do continuous integration for their projects. The simple solution and maybe the most popular is to use PhantomJS. For example, you can use the grunt-contrib-qunit plug-in and that will just use PhantomJS to run your tests. PhantomJS is pretty nice on the one hand because it’s pretty close to an actual browser and it doesn’t try to simulate it. And now, it’s actually working pretty well. So, it gets you somewhat close to an actual browser environment because it builds on top of a WebKit. I think its QtWebKit. On the other hand, it sometimes produces failures that only happen within Phantom and debugging those is really annoying, and still doesn’t cover all the issues that other browsers have. But it’s really to just get running within Jenkins and other tools and it works. It comes pretty much pre-installed in Travis, we use that for resource projects. So, that’s really easy to set up. For the jQuery projects, we kind of use a set up, that’s slightly, if not, a lot more complicated. I’m going to share a link for the show notes that describes that. The article isn’t quite up to date anymore but the basic set up is still the same. So for jQuery, we use a tool called TestSwarm which, as most of the jQuery projects was originally started by John Resig. And we use that in combination with Jenkins as our CI tool which just pulls commits from Github then the word Github does a push notification and then uses Grunt to do some basic testing, linting, using PhantomJS to run test runs and then submit the job to TestSwarm. TestSwarm is just kind of testing help. So, it accepts jobs. And then browsers which in then the testing clients can connect to TestSwarm and when TestSwarm has jobs to run, then TestSwarm will distribute those to the connected clients. There are similar tools to TestSwarm but I think TestSwarm is still the exception that it tries to just cover as many browsers as possible so that we can actually test things that every browser can support which for jQuery is the 1.9, the non 2.0 browsers are still a lot of browsers. In order to actually have enough clients connected all the time, we now use another tool called BrowserStack. This is sort of a third party platform, they sponsor open source projects so you can use it for free. It’s also really useful to do just day to day testing. For example, I use BrowserStack to do any testing in IE, sort of starting a virtual machine on my own computer. They even now also have support for mobile browsers which we don’t really use yet but are planning to make use of for jQuery mobile. So, for example, jQuery UI, the idea is I push the commits to Github, Github does a notification to Jenkins, Jenkins runs some basic checks then submits the job to TestSwarm. We have another little tool running that asks TestSwarm, which browsers do you need? When the jobs come in, TestSwarm will say, it needs five forks current and this one and this one and so on. Then, it tells the BrowserStack API to restart workers for all these browsers. Then, they test it like once or twice minutes to start and stop these workers until all the tests ran. That’s pretty much fully automated and all the tools are free to use for anyone. It’s not quite trivial to set up but once you have it working, it’s really useful. You get a lot of test coverage especially for any jQuery UI commit, if all the jobs run. I once did a calculation. We had several thousand tests running for a single commit across the browsers and different jQuery versions. So, we actually used that as well to test jQuery UI against, I think, three or even five different jQuery call versions. So, a lot of coverage there and it’s all automated. It’s not without issues. We are actually working with the BrowserStack team to get rid of the various small issues that sometimes cause all the other tests to fail. But it’s gotten a lot better over the last six months. And once TestSwarm reaches 2.0 release, we’re going to set up a proper website for that and it will become another official member of the jQuery project or jQuery Foundation. Currently, it’s not as easy to find, and currently there’s no actual website. So, Swarm.jQuery.org is what we use for our own testing. That’s one TestSwarm instance but it’s not the TestSwarm home page. So, TestSwarm is kind of on Github and you can find it and use it, and has the documentation of installing and using it but there’s no official home page beyond that. I think we’ll get there in the next few months as well. 

 

CHUCK: Cool. 

 

JAMISON: That was a really complete answer that totally pre-empted my questions about QUnit as part of a larger testing construction. So, I’m really glad you explained all that. 

 

JORN: Cool. So, I’m actually planning to, at least, put more information on the QUnit website itself about QUnit in consideration to what other options are out there. And maybe provide some code or tutorials for some of these solutions. Not sure yet which ones I’ll get to but QUnit should at least point people in the right direction so that they can find tools that are already out there or help create the tools that are missing right now. 

 

JOE: So, I have a question for you, Jorn. This is kind of an abstract question, but being as it is about how you’re involved in testing, I’m very curious about what you feel. Testing in JavaScript is hard. And it sucks. And very few people do it. So, it’s not being improved at nearly the rate that a lot of other things are being approved at in JavaScript. What do you think the future holds for unit testing, test driven development in JavaScript, continuous integration testing, full end to end testing? And what are the things that we need to get, as an industry, to make testing more wide spread in common place? 

 

JORN: That’s a loaded question. [Laughter] 

 

JOE: Yes. 

 

JORN: So, there’s a few things. Tools like BrowserStack and something that’s doing a similar thing called Sauce Labs, those are huge improvements for testing anything in browsers because they actually allow us to tell remote browsers which machines to run our tests and not bother having to set up that ourselves. And just for regular manual testing, being able to just open other tab and say open up this page and click around in there. At least for browser state, it’s a flash based player. That’s a huge improvement. That it can help for unit testing to run your tests, but it still kind of requires a lot of set up. We want to talk with the BrowserStack team. They had the idea of integrating TestSwarm into their platform. I’m not sure. As far as I can tell, so far, that didn’t go anywhere but then they also keep improving their platform a lot. So, I guess their priorities are elsewhere right now. But I think that having more tools, let’s say the combination of TestSwarm and BrowserStack, and they’re packaged up and ready to use them, it’s kind of would be a big improvement. There’s one of the things I talked about TestSwarm which actually has a database backend where it actually stores test runs. There are a lot of other tools now, for example, Testacular which comes from the AngularJS team and a few others that have the similarity with TestSwarm. What they do is if you tell the tool to run these tests, it will run them in as many browsers as possible. But instead of storing the result, they just tell you if it’s successful or not. So, they basically make a more stateless tool which you can just run in the command line. And within the jQuery testing team, we actually have a few ideas for something which one guy that I work with kind of just calls ‘TestSwarm-X’ and I don’t know if that will ever happen. But the idea there is to have something that lots of users, for example, BrowserStack or maybe Sauce Labs to run tests. But at the same time, it’s available as a command line tool that you can run locally. So, instead of running my QUnit based tests in one browser, in my case that’s usually Chrome, and when I’m done developing the feature to run the same tests in a few other browsers, I would just tell this tool to run these tests. And if it uses BrowserStack, it could run it in every browser that I support. And that doesn’t quite exist yet. For example, Testacular only allows you to point at JavaScript files that you contain your tests while QUnit has always a set of a HTML page where your tests are embedded. Both approaches probably work but if you’re using QUnit, it’s like, getting into a run with Testacular isn’t trivial even if they have -- I think they now have support for QUnit but you still have to rewrite your tests to get rid of that HTML page dependency. So having a tool that actually allows you to just say, “This is the test page I run in my browser, run that in a dozen other browsers,” that would be a lot more useful. The other thing is there’s Selenium which is kind of like democracy. It sucks but it’s the best we got. [Laughter] 

 

JOE: Awesome. [Crosstalk] 

 

JORN: I think that’s getting better. There’s now attempts to actually get the Web [inaudible] API standardized so that browsers can support that natively. And the more browsers that support that, the better these APIs get, the better tools like Selenium might get. So, I’ve never spent too much time with Selenium myself. I was on various projects where they probably used it and well, they didn’t have much alternatives. They also cursed a lot at it. So, I think getting, improving that, making it more reliable and having much less problems that are just based on the tool and not actual issues in the application would be a big improvement. 

 

CHUCK: So, I want to ask about some of the other options for writing JavaScript like TypeScript or CoffeeScript. Have you seen people writing QUnit tests for that or in those languages? 

 

JORN: So, I like JavaScript. I don’t really bother using TypeScript or CoffeeScript. And given the dark reports or feature requests I get for QUnit, I don’t think I ever saw anyone using CoffeeScript in the examples. So, that doesn’t seem to be much of a thing. So, no, not really. 

 

JAMISON: It seems like something that’s below QUnit’s responsibility though. I mean, QUnit shouldn’t really have to know or care as long as it’s something that can get translated to JS. 

 

JORN: Yeah. I guess, if you take the percentage of people writing unit tests and the percentage of people using CoffeeScript or TypeScript and multiply that, the presiding percentage is really, really small. [Laughter] 

 

JORN: So, I didn’t get to see anything. And the percentage of people actually getting involved in open source projects and reporting issues are even less. 

 

JAMISON: And the people that are using QUnit as opposed to the other ones too. 

 

JORN: Yes. So, no one from that group made it to QUnit yet. 

 

JOE: If you’re one of those two people, please dial in. [Laughter] 

 

JORN: If there is anyone. 

 

CHUCK: Alright. Well, if there aren’t any questions, I guess we’ll get to the picks. 

 

JAMISON: Any final thoughts, Jorn? 

 

JORN: There’s something -- so I mentioned we want to provide better, at least, documentation for continuous integration. The add-ons, I mentioned that BDD stuff earlier, there’s other add-ons which are sometimes related to continuous innovations. Sometimes, there’s other stuff like customizations. There are official add-ons that no one knows about. They are listed on the QUnit site but then people don’t probably look at that page. The idea is to make those more prominent and put them into their own repositories so that more people can contribute to those. And there’s some plans for QUnit itself to re-factor the code base. Currently, there’s a basic QUnit as development happens in a single JS file, we will just split that up into multiple modules that are easier to work on so you have to scroll less while working in QUnit, which should also open the way for some other features. For example, QUnit actually shows -- we talked about this deep equal assertion which tries to tell you exactly where in your objects, your key something actually differs. If you had to compare really big objects, it gets really unruly. So, we want to improve that, for example, only to show exactly which leaves are actually differing and then just show the path to that leaf instead of showing you three pages of the output. And just being able to say, “Let’s use this external different limitation,” should be pretty useful. I think that’s about it to talk about the development. So yeah, picks. 

 

CHUCK: That’s awesome. Thanks for coming on the show. We really, really appreciate it. And QUnit is definitely something I’m going to be looking at in the future because I’m one of those people who tend not to test his frontend. [Laughter] [Crosstalk] 

 

JAMISON: Joe’s going to try and punch you through Skype right now. He’s going to come out of the speaker. 

JORN: So there’s one more thing. We mentioned in the beginning this intro to JavaScript testing article. That actually has one important lesson that, don’t try to unit test your application. That just doesn’t work. You’ll just get frustrated and give up. Try to figure out which part can I actually put into a small module, library, like a jQuery plug in, and then write a unit test for that. That’s so much easier and so much more useful. So, focus on testing modules or libraries. Just don’t bother testing your application with unit tests. If you put everything into small modules and test those, then you probably don’t even need to bother trying to write tests for your application. Just click through the UI and that might already be enough because all the details, the error handling has already covered. 

 

CHUCK: Yeah. I started doing some of that and playing with, I think, I was playing with Jasmine at the time. But I fell into this project where the frontend is this huge, huge mess of ext.JS. And yeah, not a lot of the logic is really broken out in a way that you can test it. And so, that’s part of the problem. I’m also curious though, as far as -- I kind of came across my own answer. I was going to say, how do you test the DOM interaction on different pages in your application? And that’s what you were telling us not to do and instead you moved that functionality into a module and then you just inject the DOM elements that it cares about into the page when you run the unit tests. 

 

JORN: Yeah, that usually works pretty well. 

 

CHUCK: Alright, cool. Well, let’s get into the picks then. Jamison, do you want to start us off with the picks? 

 

JAMISON: So, my first pick is, it’s a gesture tracking armband. I think it’s called MYO, My-O, or something. And it is this band that you put on your arm that looks kind of like a sweat band. And it tracks the electrical signals that your muscles give off when they contract. So when your fingers move, it can actually track individual finger movements. And then, it has some gyroscope or accelerometer things to track larger gestures of rotating your whole arm or things like that. The intro video looks really cool. It looks like it could all be totally fake as well. So, I’m not sure how real or how actually production-ready this is. But it looks really cool. So that’s GetMYO.com. And then, the second pick is, it’s the Mailbox app. That app that shows you numbers going up and down and you hope eventually when your number gets low enough, that you’ll actually be able to use it. My number finally got low enough. I finally got into it. And I think it’s brilliant. Their marketing idea, it’s only like a limited number of people because people want what they can’t have, you know? If there’s this exclusive club of people that can use this app that you can’t get into, it kind of makes you want it more. So, I think it was a really smart idea of them to show explicitly this queue of users that are going to be able to use it eventually and where you are in that queue. The app itself is great too but I just thought the marketing on that was sweet. 

 

CHUCK: Nice. Alright. Joe, what are your picks? 

 

JOE: Alright. So for the second week in a row, I think I’m going to do a little selfpromoting and pick my course just because it actually has a module on QUnit. So, if you’re curious about using QUnit, I’ve got a really nice, about hour long video on how to use QUnit and getting started with QUnit. And once again, you can get online. It’s a free seven day trial. So, you don’t have to pay anything. My second pick is the one I’m most excited about. It’s called Dragon Box. It’s an IOS, an Android game. And I think you can get it for both phone and tablet. And basically, it’s a game. It’s an educational game but unlike every other educational game I’ve actually seen, this is far more game, it hides the education so well. It’s for kids and it basically teaches Algebra. I talked with a developer, who I don’t know if they worked on it or not, but he’s familiar with it and showed it to me and we talked about, it takes about three hours to get the whole thing. And by the end of three hours, you basically mastered basic Algebra. And it takes like an hour before you realize there’s really any actual Math going on. I’ve had my 10-year old and my 8-year old playing it and gotten pretty far. And I’m excited to see when they finally finish up how competent they are. But I’ve lived through it and played through it and it’s just amazing that it introduces the concepts of Algebra in solving equations, basically solving for X in such an effective manner. My kids, they love playing the game. They are completely addicted to it. I don’t give them enough time on my iPad but they absolutely love it. It’s a sweet game. It’s like $5 I think, and again, it’s called Dragon Box, love that. And then for my third pick, I feel a little silly picking this because I don’t know tons about it but I’ve heard a lot of really awesome things about it. It’s Breeze.js. It’s a new library for basically handling rich data in your JavaScript applications and it plays really well with existing MVC tools like Angular, Backbone, Knockout, or just anything hand rolled. I’ve heard some friends of mine have been doing a lot with it and I’ve heard really good things about it. So, I’m going to pick that as well. 

 

CHUCK: Awesome. Alright. Well, I’m going to go next with my picks. My first pick is, it’s an Anker battery pack. It’s something that you can plug your phone into and it will charge it up. And it is super, super nice; really, really enjoyed using it. I actually took it with me when I went to the Parade of Homes in St. George, Utah. And my phone, while we were driving around, I’d play games on it and stuff, because I wasn’t actually driving. So, I’d plug it into this thing and it charged my phone up, I think, twice over the course while we were out there, while I was playing the game. And it was still not even halfway empty. So, it works out real well. It has two USB plugs on it. So, I could plug my phone into it and charge something else off of it at the same time. And I’m really looking forward to being able to use this as I go to conferences and stuff to maybe charge this up and charge up like my video camera or something and make that all work. So, that’s one pick. And I’ll put a link off of Amazon for that. The other pick that I want to do is I got an invite from a friend of mine to App.net which is kind of a Twitter clone except the user interface is a lot cleaner. There aren’t as many people on it which is kind of a plus and a minus because I don’t get a ton of stuff I have to follow. But at the same time, not all the people that I care to follow are on there. So www.App.net" App.net, it looks really good. It has some of the same kinds of third party applications that people can use to use it. And it looks like their opening up a free tier because my invite was for me to get in for free. So, I’m thinking eventually people will be able to sign in for free. And hopefully, they won’t do some of the goofy stuff that Twitter’s done. Yeah, those are my picks. 

 

JAMISON: Wasn’t that the whole point of HYPERLINK "http://www.App.net" App.net, though? That they would always charge so they would never have an incentive to try and make money off of users because they would make money off of letting users into the service, not of monetizing their accounts and stuff? [Crosstalk] 

 

JOE: Basically, they’re saying that their product is the product and rather than the users are the product. 

 

CHUCK: Yeah. 

 

JOE: They’re not selling you. They’re selling you the product. 

 

CHUCK: Yeah, that was my understanding. I don’t know how that all fits into their strategy. But I guess that’s that. Anyway, I’m in. And I’m in for free. So, whatever that means. But yeah, the rumor is that they’re going to open up free tier. Maybe they’ll add more features for people who sign up at the higher levels. I don’t know. 

 

JAMISON: Maybe your posts will all be in Pig Latin or Comic Sans? 

 

CHUCK: Nice. Alright. Jorn, what are your picks? 

 

JORN: It’s funny that you mentioned the Anker. I actually ordered one today since I got an invite through Ingress. I can’t really talk about Ingress though but you can look it up. Related to the motion detector that Jamison mentioned, I ordered a leap motion last year. And I got an Email that they promise to start shipping that in May. So apparently, the developers that sign up is developers that already got one but I’m looking forward to actually trying that myself. It’s a really interesting device and that it’s basically just a camera that looks at all your finger movements and it has a really high precision so it can see really small movement. So, it’s kind of like Minority Report except that you don’t have to wave your entire arms. You can just rest your arms in a desk or chair and then move your fingers around a little bit and it’s supposed to already work. So, I’m looking forward to trying that myself and you can still pre-order them. Finally, I’d like to pitch something that I’m working on, not as part of the jQuery project, but it’s a jQuery plug-in of mine. It’s called the jQuery Validation Plug-in. And I’m actually looking for people to donate for that. I have a Pledgie campaign running. And it’s only asking for 4,000 Euros. It still requires some -- it’s still quite a way to go. It’s like 43% now. And the Pledgie campaign, it actually has a lot, pretty detailed road map for the plans I have for this plug-in. And since there’s like at least a few hundred thousand sites using it, according to transwidth.com, I hope to reach more people that actually use this plug-in to donate to the development so they can put more awesome features in and get a proper work setup and running. Everything about this plug-in is just as open source as the jQuery stuff is so. It’s not that you have to pay me to get great support or something but you just get to get a better plug in that does really good form validation and does it really well. 

 

CHUCK: I think I’ve actually used that before. How long has it been around? Quite a while, hasn’t it? 

 

JORN: Yeah. I started that 2006. So, it’s been around awhile as well. I have some baggage that I need to get rid of. Since a lot of people are using it, they also find a lot of issues that you wouldn’t ever see if you just write a small plug-in for your own site. But then, it also solves a lot of problems that you might have. Kind of like what jQuery does for other issues. So yeah, if you’re using that plug-in or would like to use it and want to see it get better, I appreciate donations or just spreading the word. Would really be useful to find a company that has a lot of projects where they use this and would be really interested in doing a bigger donation since having like five or ten Euros every once in a while doesn’t really get me far. It’s not bad, I appreciate those as well. But it would be interesting to get a company that could afford a bigger donation. 

 

CHUCK: Cool. So, if you want to sponsor it, go check it out. Do you want to put a link in the show notes for us? 

 

JORN: Yeah. I think I did. 

 

CHUCK: Alright. Well, we’ll warp up the show then. Thanks for coming, Jorn. It was really good to talk about this and hopefully, we get a few more people testing their code and get some higher quality code out there. 

 

JORN: Yeah. I hope this helps to promote JavaScript unit testing in general. I don’t really care that much if you use QUnit or something else, just more people should do JavaScript unit testing. 

 

CHUCK: Yup. Yeah, and hopefully that will lead to better code overall. 

 

JOE: Amen.