The crew discusses testing with Ward Bell.

Transcript

JOE: You sound sexy! WARD: I feel sexy. You should see me.  ** [Does your team need to master AngularJS? Oasis Digital offers Angular Boot Camp, a three-day, in-person workshop class for individuals or teams. Bring us to your site or send developers to ours --  AngularBootCamp.com.]****[This episode is sponsored by Wijmo 5, a brand new generation of JavaScript Controls. A pretty amazing line of HTML5 and JavaScript products for enterprise application development, Wijmo 5 leverages ECMAScript 5 and each control ships with AngularJS directives. Check out the faster, lighter and more mobile Wijmo 5.]****CHUCK: Hey, everybody and welcome to Episode 26 of the Adventures in Angular podcast. This week on our panel, we have John Papa. JOHN: Hey, everybody from sunny Florida! CHUCK: Joe Eames. JOE: Hey, everybody! CHUCK: I'm Charles Max Wood from devchat.tv. Before we get started, I'm just going to mention this: I am swallowing a little bit of pride here, but I have been basically paying for the podcasts that you listen to for a while and things got a little tight over Christmas, so I'm going to ask you to help us out. The way you can do that is you can go to devchat.tv/donate, and you can contribute there. Also, if you want to get something back for your dollars other than the podcasts, you can go sign up for JS Remote Conf at jsremoteconf.com. And finally, I am also putting together an e-book and a course on podcasting. So if you're interested in podcasting, go to pickuppodcasting.com. All of that will help support me and through that, help support the shows. So I really appreciate everybody listening. I don’t have any plans to cancel any of the shows at this point, but things have gotten a little bit tight. So if you could help me out, I'd appreciate it. We also have a special guest this weekend that is Ward Bell. WARD: Hello from foggy San Francisco! CHUCK: Foggy, huh? WARD: The fog rolled in today, which is actually kind of mystical kind of thing. And I hope I'm not as foggy as the weather, but we'll see. CHUCK: Yeah. It's snowy here. Right, Joe? JOE: Indeed it is. CHUCK: Yeah. All right, well, we're going to kind of give an introduction to testing Angular. So, I'm wondering where should we start with this? Is there kind of a default stack that people use or is this kind of up to the listener? WARD:**Well, I think you have a lot of choices. By the way, we might start by actually talking about why we bother testing at all or how much testing we actually do. Through my company IdeaBlade, we make BreezeJS (this is a framework for data access) and we have evolved, in one form or another over a decade and I can tell you that we really relied on a battery of tests to help us over those years because we've changed technologies, we’ve changed our ideas about how to do things. But there's a certain continuity in the functionality and without those tests, we wouldn't have the confidence we have that as we have evolved across all these wildly different spaces and these different ideas, that it still is delivering the kind of value and functionality that we thought it would. We wouldn’t have that confidence if we just didn't have these thousands of tests, so it's been fundamental in our lives. And more recently, I took a whole bunch of tests that we did for Breeze that were written QUnit for Knockout and have been redoing them in Angular. And so that’s kind of lead me down the road to knowing something about Angular testing. I got my start on that by listening to Joe Eames’ Pluralsight course on testing. So, Joe, maybe you wanna talk about that.**JOE:**I have a Pluralsight course on testing. [Chuckles]CHUCK:[Chuckles]**JOE: I have a couple of courses; I have a course that’s just about testing in JavaScript that talks about the different frameworks, QUnit, Mocha and Jasmine and other aspects of testing. And then of course my fundamentals course on Angular talks about the basics of testing in Angular. There are other Pluralsight courses that talk about testing of Angular as well. I believe that there's one called Test-Driven Development with Angular from Scratch. So, there's quite a few resources out there on Pluralsight just for testing with Angular or just in JavaScript in general. WARD: And how does testing fit into your day job? JOE:**Me? Well, my main day job is as an author, so when I'm authoring a course on testing, then it fits in. [Laughs]**WARD: Well, I know John Papa, it's not just sort of academic interest for you. JOHN:**Testing? No, it's something I loath to the deepest part of my soul, actually. [Laughter]**JOHN: No, I do a lot of testing. And honestly, I'm not a big fan of writing tests -- and Ward and I have had lots of chats with this in the past -- and I think the reason is not the tests; it's the time that it takes to actually get to write a test. It's all that setup, and garbage that you need to do before, the friction to get there. WARD: Yeah. Well, you and I have talked a lot about how to make testing easier on us, so that it becomes a natural part of the development flow. CHUCK: So I have a question really quickly; you guys all write bugs and I get that. I mean, some people do and some people don’t. And I don’t write bugs, so why should I write tests? WARD:**Well, because you're better than us, so you probably don't need to. [Laughs] Like I said, for me there are at least three reasons: one is that I find it provides sort of architectural push back. And what I mean by that is when I’m writing a piece of code and I'm kind of going along with the tests to sort of figure out what it does, (and I'm not talking about TDD here, I'm just talking about “test soon development”), if I can’t test it really easily, then that’s a really good indicator that my architecture is not too good; that I haven’t really designed it very well. So I find it first of all to be a great check on whether I’ve laid the thing out properly and have an API that whatever it is I’m writing, that I like. So I think it's great there even if you never use it for anything else. I talked earlier about how critical it is for us in catching regressions -- particularly as we rapidly evolve our library called Breeze -- because we wanna have the freedom to be able to sort of stretch it, add new features, change the implementation because it wasn't as good as we want it to be. And without those tests sort of hamming it in, we wouldn't be confident that we weren’t breaking things in the process. And indeed, one of the things you’d find out as you begin to change things is your tests start to fail and now you realize what you did wrong before you’ve inflicted that on your users. So it's been helpful that way. That was the second way. The third way is it's been a great way to convey to others -- and to myself almost -- what the heck it is that the component is capable of doing and what the constraints are and the limitations on that. So I don’t just ask that it works; I throw things at it that I think will go wrong -- that will typically go wrong -- so that I can see what the behaviors of the component will be in what our [unintelligible] cases surely to arise. So those are three forces that make me test. And maybe they are forces that would make you test even though you noticed that I… well, in one case, I was talking about bugs but for the most part, I'm not talking about bugs; I'm talking about design and communication.**CHUCK: I was going to say, I mean, that last point for me is that, you know, I just assumed that the other guy working on the code is an idiot. Of course, that “other guy”, 99% of the time is me… JOE:**So are you usually writing your assumption? [Laughs]**CHUCK:**Yeah. [Laughs] In a lot of cases, I mean that's why I write tests is that I write the code and then I write the tests. Sometimes I write the code before I write the test before the code. But in either case, a lot of times what I find out is that, “Okay, now that I've written this and I’ve got a test on it, I've learned something and I know that there are places where I can improve,” and so the refactoring goes more smoothly once I have the test in place. Because I know what works – or at least I know that the case that I am pushing through the test works --  and then I can start to flesh that out and make sure that it does exactly what it's supposed to do under all conditions that I think it could hit.**JOHN:**Yeah. I think a lot of the places I like to use tests the most are, again, not for bugs but for communications. So, a lot of times, I deal with a lot of developers who have to read someone else's code. And sometimes they read the readme files and sometimes they read the code itself. But other people like to actually look at the test or, “How do I use this thing?” And the tests often can be a great way of self-documenting, “This is how this API is intended to use and how it's intended to work. And also, here's cases where you can use this API and it won’t work because you’re passing the wrong data, because those are your failure test cases.” And then the other side of that is, just making sure the standard [inaudible] something went live, we made an enhancement to it and with that enhancement, now we have a full suite of regression testing to make sure we didn’t break anything else in the process. So those are the two big reasons I like to have tests in place. And to be quite honest with you, that case doesn't happen to me as much as somebody’s coding something. And while they are writing the test, (they’ve already coded it they are not doing test first, they are doing the test during development) somebody codes the thing up, they think they’re done, then they write a test and realize, “Uh-oh, this thing didn’t actually do everything I thought it was going to do. I better refine this now.” So it’s actually before it ever goes to production, we're finding some of the issues.**WARD: We have a rule around our shop too which is, we don’t like get the 100% coverage, but we do have this rule which is that when somebody finds a bug, we have to test the bug; surround it with a test that reveals the bug and only then are we allowed to fix it. And that's just a rule around the shop, and so it's amazing how we've accumulated a good battery of tests, just by following that rule. JOE: Now, John and Ward, neither of you guys are TDD-ers, then? WARD: Nope. JOHN: Nope. Not at all. I’m a “test during development” guy. WARD: I do use TDD in the spot cases. Like the other day, I actually did use something that approximated TDD and that was when I didn't understand the problem. Usually when I'm writing code, I’m pretty much banging in and out and I know what I’m doing, but there are occasions when I've got something that is just so mind bending, that I can’t keep track of what's going on unless I write the test essentially first to sort of say, “Well, this is what it's supposed to do. Now let me see if I can implement it to do it.” CHUCK: I’ve found though, Ward, that in a lot of cases, unless it's something I've done over it over and over and over and over again, I’d need that level of exploration. And so I do TDD a whole lot more often than I don’t for that reason. WARD: And that’s fabulous. If you can follow that pattern, that's great. I think it may be that I'm too old and I'm too stuck on my ways. CHUCK:**As long as it works, right? I mean, ultimately, the value that you're providing is working code. And so if you write the test afterward or you write the test beforehand, I don't think that matters as much. What I think matters is that you go through the process of writing working code, you get some tests around it, you figure out where you need to refine the code or refactor the code, and then you move along. And one other reason than I like tests (and you kind of implied it with your reasons, Ward) is that because I have the tests and because I have this system that kind of provides checks on what I'm doing, I can actually move ahead with less fear and less double checking of what's going on in the system because it'll tell me when things break. And so I can go in and I can refactor or add new features. And if I go in there and I make a change in something in a way that breaks the assumptions on that code, then I get told. And so then I can make the call as to whether or not those assumptions are no longer valid or whether or not that's something that I need to go back and work out, so that all of the assumptions that apply to the code work so far.**WARD: That makes sense. So I have a question for all of us: we're talking about tests, and it looks like we're all convinced, but I don’t know about you, I also have a lot of clients and I can’t tell you how many of them tell me, “Hey, so you wanna know about testing? Do you have tests?” And they look and they sort of look at their shoes and then they say, “Well, we've been thinking about it but we don't actually do it. We don’t have any.” Is that pretty much your experience? JOHN:**Dan Wahlin and I did a workshop – actually, two of them -- in December and in both of those, we had about 150 – 200 people in the room, all [unintelligible] over Angular. And at one point, testing wasn’t part in the curriculum, I said, “Look, we have an extra hour here. We'll cover anything you want. Who wants to cover testing?” One person raised their hand. I'm like, “Okay, who here understands testing and actually does it at work?” Two people raised their hands. It was one of those things where it was like, “Please don’t bring this topic up again.” [Laughter]**JOHN: So it's interesting and then we all talked about it. And I think a lot of people do it more than they want to admit but I think there is such a stigma with doing testing for different reasons; it's either hard or budgets get constrained and people don’t have time to do it. But, Ward, you’ve done a lot of stuff specifically to make testing easy; to get the friction out of the way; I'm curious if you can explain some of that to some of the people to make this a better story. WARD:**That’s exactly right. I'm curious about this too, because we know that it saves our butts, but the customers, you may ask them about it, and often they’ll tell you, “Well, we tried it for a while and we ran into two things: one is we spent too much time writing tests and we weren’t getting the code out, and so our bosses got pissed at us; the second problem is that we wrote the test but then we’ve changed the code and the test started breaking. And we didn't have time to go back and fix them, so we started commenting them out and then we didn't trust the tests anymore and it was all over and we just quit.” [Laughs] Those were the two stories I hear over and over again. And I'm very sympathetic because I've done that to myself. And I'm trying to look and sort of say, “How do I cut those things down?” How do I, (A) Make it really fast to write test and easier to write test; and (B) how do I write them in such a way that they aren’t always breaking on me? I think we have some ideas about that and there’s a motto that you and I have gotten to, John, which is called like that “what's the shortest distance to the first it?” [Chuckles] Now in order to understand that, you have to understand the test framework. So what we're tending to write our tests in is something called Mocha and we use [unintelligible]. So when we use Mocha or Jasmine or something like that, the very first test that actually does anything is “it” -- the function verb is “it” – it does x and it does y and so forth. So, it's this “it” verb. And before you can get into that “it”, that first test, usually have to set things up. You have to set the conditions for the thing that you're going to test -- and that can be lines and lines and lines of code. And often, when I see people's bad tests, they've got miles and miles of set up before they ever get to the first test – the first “it”. And so we've been concentrating a lot on what can you do to keep that distance – all that setup -- reduce it to an absolute minimum, so you're not spending all this time setting up and clearing your throat before you actually get to the test. And that's really where we're focusing. Does that ring true to you guys?**JOE: I would say for the most part. I'm kind of curious, Chuck, you said you’ve practiced a fair amount of TDD. Is that right? CHUCK: Mh-hm. JOE: Okay. And Ward and John, you guys are kind of “test during”? JOHN: Yes. CHUCK: I’m shying away from my… I do have one admission to make and that is I typically don’t test my front end JavaScript. So this is something that is very interesting to me. And I'll tell you what the barrier is for me is that most of the JavaScript frameworks that I used to test my frontend JavaScript, they don't fall in line with the other backend framework testing stuff. So you know, I go ahead and I run the script that runs my tests, and you know I get feedback on the command line, but I haven’t found a great suite of tools that will allow me to do the unit tests at least from the command line that work out nicely. I mean, I can use Selenium web driver or whatever you wanna call it, but that takes time. It doesn’t run quickly and you know, a lot of the other ones like Jasmine and stuff are designed to run in the browser. And so in order for me to get feedback, I actually have to go look at the page. WARD:**Oooh, you’ve got so much to learn, I can’t wait until you take some of our courses.  [Laughs]CHUCK:[Laughs] Yeah, fix me. Go ahead! [Chuckles]**JOE: Well, just in full disclosure, since 2005, I've been a pretty much 100% TDD-er. I read Kent Beck’s book and fell in love with the concept of Test-Driven Development and I became a full-time TDD-er. And when I went into JavaScript, that was actually one of the things that drew me to the frontend was the fact that the front end was new, and it was interesting but almost nobody was testing in their frontend and nobody was test driving in the frontend. And so I went to the frontend to: one, figure out how to do it; and to show people that it was a viable practice. And anybody who’s listened to JavaScript Jabber a lot will know this about me. The first time I was on JavaScript Jabber was to talk about testing, but I'm a big fan and a big evangelist for Test-Driven Development. And I practiced it 100% in pretty much every JavaScript project that I’ve written that’s been anything other than a toy. When I worked at Domo here in Salt Lake City, we had an application with a hundred thousand lines of code of JavaScript and kind of the big reason they hired me on was to bring testing into that. And I spent all my time trying to get everybody to test drive their code. And so I'm a huge fan of test driving your code, and I feel like that’s a superior way to get tests into your code. And I even wrote a big long article that was on Dr. Dobbs, all about why Test-Driven Development is a superior form of doing development.  I can give you a grudge match about not just about anybody who says testing is a bad idea, but people who would say that test-driven development is not a good idea. WARD: So that's kind of cool. Were you able to spread the gospel throughout Domo and get everybody doing it? JOE: Nope. I converted like three of the twenty frontend developers. And for the most part, the rest of them... I mean, I converted everybody that paired with me with a pretty significant length of time. WARD: And you know, everybody was talking about the DHH’s… I don’t even know what his whole name really is. CHUCK: David Heinemeier Hansson. I’m a Rails developer, so I know David. Anyway. WARD:**Yes. So he just came out strong against TDD and that created a big furor. Now we can really hijack the show and… [Laughs]**JOE: I need several references to him… references to that article since that's come out, and both this show and the JavaScript Jabber show, we’ve talked about that at length in fact a little bit. JOHN: I'm going to kind of divert this back with some of the toolings. I think Chuck brought up a really good point though is when you get started, how do you even know what tools are available because most of the demos that we see out there are like what Charles was referring to when you run JavaScript testing is looking at the test in the browser. But if you wanna just run your test in the terminal to see, you know which ones are automatically failing or passing or through some kind of test runner tool or through CI process, what are the options that are available that you’ve explored that are either good or bad, Joe or Ward? JOE:**Well, what's nice about Angular is it's built from the ground up to be testable. I assume that most people that listen to the show know (but maybe not) that when Miško created Angular… his job at Google was bring testing to other departments. That was his whole main job at Google. And he wrote Angular while… it was just a side project, but his focus and his purpose at Google was take testing to the groups. So he built Angular from the ground up to be testable. So I think one of the great things about Angular is it itself encourages a lot of testing and kind of leads you towards some of the tools. Obviously Karma is your kind of first step there. And then there are still other missing pieces. You can’t just have karma by itself. There are missing pieces that you need but since this is a show about Angular, I think it's worth talking about the fact that Angular itself kind of says, “Hey, testing is here. It's easy to do.”**JOHN: That’s a great point. I mean, there's so many players; there’s Angular itself and then Angular mock, the library that come with it that help you mock out the Angular assets or components, if you will, but then there's also things like Karma which runs your test; and then there's… you choose Jasmine or Mocha or one of the two to actually write the tests. And then you’ve got to do stubbing and mocking at some point, so you might wanna use something like Sinon or just use Jasmine. So there's different tools and I think that's where the cognitive overload comes in because there's so many things you have to look at and understand to make these moving parts work together. WARD: Yeah. So what we need to do is  be able make to make runway a little clearer, smoother and quickly answer… at least give some comfort to questions that Charles has there. So, yes, by the way, Charles, with Karma and the out of the box runner, you’ve got that at the command line and you’ve got that just playing in the terminal window and you’re not having to go through a browser. So you can absolutely have tests and watchers going at the same time, so that the tests are just happening automatically and off to the side, so you can see the results. Is that what you were looking for? CHUCK: That’s definitely part of it. I do the same thing for my Ruby code. I write my back ends in Rails -- most of the time, Rails or Sinatra -- which are both Ruby frameworks. And I know I do the same thing; there are systems that run those. I just haven't had an opportunity to figure out how to set that up for JavaScript. And then systems like Jasmine look a lot like Rspec. In fact, Jasmine was loosely inspired by Rspec in Ruby. So you know that's not so much a stretch for me. WARD: I think if you've been used to testing in some other environments like you have in Ruby or those of us who've been testing in C#, all the concepts, all the machinery, there's a corresponding something or rather over here in JavaScript and we just have to show people how that works. And by the way, Karma is not a limited to Angular, just for people who know. For example, it's being used by the Azure Portal people who are writing everything in Knockout, and they use Karma to drive the whole thing. So yeah, the machinery is there; we just have to educate the world about how to get to it. JOHN:**So I think one of the things that we're kind of dancing around too is once you get your test set up, you have to run these and get them moving along. And I don’t know how you guys feel, but I personally feel that testing is not complete unless you have its brother -- which is a Gulp or Grunt process -- to kind of run those. And the reason I think that's important is yeah, you can go to the command line and run Mocha, and start things up or Karma or whatever, [unintelligible] HTML, but having some kind of Grunt or Gulp process to actually wire up the test and run those for you, I find that to be immensely valuable.**JOE: So that’s one of the reasons I love working in WebStorm is that WebStorm has lots of listeners, that it will put in… you can either run Karma within WebStorm to do all that for you, so you don’t have to get into Grunt or Gulp. Not that getting into Grunt or Gulp is bad; in fact, I think if you're not doing Grunt or Gulp, that’s something that you're missing out on and you should be doing, but unlike WebStorm because it kind of eases that pain a little bit and says, “Hey, you don’t need to put together a full on build process if you want to test. I can get Karma running, but you want it inside of your IDE and you don’t wanna run it from the command line.” I like WebStorm for that a lot. JOHN:**That’s a great point because WebStorm, and now, Visual Studio, recently supports Grunt and Gulp too and Karma, so you can… well, actually, not Karma yet, so you can run those things through those IDEs as a developer. There's just two reasons I kind of link back to Grunt and Gulp, and it depends upon the environment. The shops that I work in, we use literally a dozen different IDEs, so I can't say “go use WebStorm,” which I’d like to be able to do because everybody has their own favorite; some people use Vim; some people use Textmate, Sublime, Brackets, WebStorm, Visual Studio – the list goes on and on. And so that in itself kind of leads me away from there. But as far as easing into it goes, I love using WebStorm to actually run my tests because I like the Visual Karma tool. If you [unintelligible] the little runner that it runs down there, that is just to me, it's the best runner – visual runner – that’s out there today. And I'm kind of hoping more of those will come out.**JOE: Totally agree. So that’s one awesome thing about WebStorm; it lets you ease in, so it will let you start off with just writing Karma, and then since it will run Grunt or Gulp for you, when you need a more full… when you wanna do more than just run your tests as change your code but you actually want to do a more full-on build, or you wanna get grunt or gulp running your tests and you can switch over, but now you got grunt and gulp running karma and WebStorm was just running grunt and gulp so it lets you step in incrementally into the process. JOHN: Right. And you can still hook into CI either way. So a CI process can run grunt or gulp, or it can actually run the karma runner directly too. You can still do CI without Grunt and Gulp; I just found it easier. JOE: Yeah. But I think that probably if you are an open source frontend developer, you're probably not afraid of the CI, but I do feel like a lot of more closed source backend developers that are getting into frontend are probably looking at this thinking, “I'm not used to having a command line to open all the time, running some important processes as an important part of my development stack,” right? Or development process. JOHN:**I would agree with that. That’s been my observation. [Chuckles]**JOE: So it's nice that Visual Studio and WebStorm have built in pieces that will do front end testing for you and let you… WARD: That’s a great point. JOE: Yeah. JOHN: Yeah. I think it's awesome because sometimes you wanna test your tests too or you wanna debug tests and something Ward and I have done is we use terminal a lot to watch our tests but as we all know when a test fails, sometimes you get hundreds or thousands of them. When a couple tests fail, it's really hard to scroll through the terminal and figure out what the heck went wrong. So that’s where a test runner inside of an IDE or in a browser really is helpful. WARD: Totally. CHUCK: Yeah. WARD: So I think you really covered an important point there which is how do I get then the tooling to help me make my tests easier? And WebStorm is a great choice there. Then there’s actually writing the tests which is… so Charles, you're kind of the Guinea pig here for us; if you had a great tool that was running the query automatically like that, what's the next reason that sort of keeps you from writing frontend tests? CHUCK: I’ve got three letters for you: D-O-M. Writing unit tests is pretty easy, right? If you're testing some logic, you know, I’d put this input in, I’d get this input out, blah, blah, blah, it's great, but then when I have tests that I wanna run against the DOM, it seems like the major problem there is that I can either write unit tests -- which are fast – but then I kind of have to simulate the DOM or put the DOM elements on the page that act like the DOM or you know, have some kind of fake DOM tool, and so I don't have something that looks or feels or acts just like the page that I’m interacting with. And so, I start reaching for acceptance tests, which I like to run on CI, and I don’t like to run them on my own machine because they are not fast. So there's a little bit of disconnect there as far as, “Okay, how do I know that if I'm testing this directive or testing this two-way binding, how do I test that it behaves in a particular way and know that it's going to do the same thing on the page when I need it?” WARD: So that's fascinating because you're describing the kinds of tests that I don't write. Maybe Joe does, but are we talking about testing single page applications here? CHUCK: Does it matter? WARD: Yeah, I think it does and I'll tell you why because what I'm usually trying to test… I am writing single page applications, and so what I'm usually doing is writing controllers and logic that governs the movement of the application as it's executing on the client. And so the code that I tend to write is all about like, “Did it show the right thing at the right time? Did I get the right thing at the right time? Did it go the right place and I said it should go?” Those are the kinds of questions that I'm after because that's the kind of logic I'm writing. And I simply sit back and assume that the bindings are actually going to work. In other words, I don’t test the DOM that much because… I'm saying, you know what, those Angular guys, they’ve figured that out; if I write a controller and it exposes the first name property, then I don’t need to test whether the first name is actually showing on screen. That isn't where the lion share of my testing problem is; the lion share of my testing problem is did I have anything to show in the first place? And is it the right thing I'm going to be showing? And so I don’t write tests against the DOM unless I'm writing a directive that does DOM manipulation -- and I generally stay away from those. Not that I don't think you should know how to test them, but I would say it's a small fraction of the kinds of things that I'm testing. So what's different about my experience and your experience? CHUCK: Well, when you say something to the effect of “single page app,” let me back up the second and when I'm using Angular, I mean, technically, I'm sort of writing a single page app but usually I have like a landing page and a log in/log out page, and you know, maybe one or two other pages that might be static pages that don't fall under the single page app. And then a lot of the other rich functionality where I'm manipulating data and moving things around, clicking different areas on the screen; those are the things that I really care about. And I can see that yeah, you just assume the bindings work. That makes a lot of sense. I mean, there are things in Rails that I don’t test for the same reasons you’ve just outlined. But let's say that I do write a directive that creates a widget of some kind on the screen. So I am going to need to test that, and it is going to interact with the DOM in particular ways, and I can unit test some of that, but a lot of it is going to come down to how it manipulates the DOM and how it uses the data that is already bound in one way or another to make that widget work. WARD: Yeah. I have to agree that those are the harder tests to write. You know, we have recipes for showing… you know how you can begin to approach testing the kind of widget directives that you're describing without engaging a full on.. the DOM in the sort of slow and awful way, but ultimately, I guess you want to do end to end tests and there's separate tooling for that. And I don’t consider myself an expert on that. Maybe Joe has something to say about that because I can just say that in a percentage basis of the code that I write tests for, I have to say DOM manipulating code represents some less than five percent of the code that I am trying to test. So that’s why I guess we have very different experiences there. And much of the advice I have for people concerns how they can go after the other what I call 95% of my tests, which is usually how do I make sure that these controllers, the Angular controllers I'm writing or the services that I'm writing -- and I write a lot of both -- how do I make sure that they're doing what they're supposed to do? And I can do that without actually engaging in that DOM at all. Joe, what is your thought about Charles’ dilemma? JOE: Well, I'm pretty much the same way. If I'm writing Angular code, pretty much the DOM manipulation that I'm doing is inside a directive. Directives are fairly testable. In fact, they are quite testable, so getting your DOM tested within a directive or getting a directive to test well, usually isn’t too much of a problem. And of course, there are challenges with that, but my biggest thing I’ve spent time on mostly really is what you said, I'm testing my controllers and my services, mocked back ends, that's where the real logic sits at. That's where I end up spending most of my time testing. And I worry a little bit less about the DOM manipulation testing. I kind of feel like if I've tested them, major cases of DOM manipulation and they're working then I don’t worry so much about the edge cases if I test them once or twice manually. JOHN: I also feel like a lot of the DOM manipulation stuff, I don’t spend as much time there either, Joe and it's because the DOM manipulation stuff for me tends to rise to the top anyway; meaning either through QA or to general use and development. If a controller directive isn’t going to be working the way that it should be, it usually presents itself pretty early and during my own developer testing. Whereas a lot of the logic that’s in service and controllers in the backend, like talking down the node and whatever I’m talking to, that stuff may not surface, and so I have to have a test for that. So I'm not advocating not doing DOM testing, but focus a little less heavily on that than I do on all of the logic and code. WARD: I should say that we have the same separation or the same set of concerns when I was writing in Silverlight or WPF or one of those other native experiences. And that was what led us in those spaces to have a very strong separation between… some kind of MV* pattern. One of the driving forces for that pattern was that you could sort of isolate the parts that were harder to test, that involve manipulation of visual on screen and pixel concerns and things like that in a view, which you could just if you try and keep all of the logic out of that that you possibly could and rely on a binding framework of some sort to guarantee that you could get to that when you need to do it, so that you could put the lion share of the focus on the non-visual code that drove it, like a view model or controller or something like that. That was a motivation for it in that space. And again has struck me that’s the motivation for that separation when we write single apps in JavaScript. And in fact, that's one of the lovely features of Angular is that it is so strong on that separation. For example, we have a running rule that says “You don’t do DOM manipulation in a controller.” The one place where DOM meets JavaScript is in directives. And so we’ve kind of isolated that whole problem of that interaction which is it's not that it's impossible to test, but you have to admit, Joe, that it's a little harder to test because you have to do something. And so we've isolated that in the directives to do DOM manipulation leaving the rest of the space blissfully free of DOM interactions so that it's much easier to test. JOE: I definitely agree with that. CHUCK:All right. Well, we are way past our time. [Laughter]CHUCK: But this is such an interesting topic and I love all the answer I’ve gotten. And yeah, I'll do better testing my JavaScript. So maybe in a week or two, we can maybe go over which tools to look at or which tools to use. WARD:Yeah. I think it's a real fertile ground and we could start having a session where we got down the [unintelligible] and looked at some of the very specific toolsets and practices. But this was great for me and I hope for the listeners; orientation towards sort of the ways in which we encounter testing in our lives.CHUCK: All right, well let's go ahead and do the picks and tips. Joe, do you have any announcements about ng-Conf, before we get too far down the road? JOE: Yes, we do. We have announced ng-Conf Extended. Ng-Conf extended is the opportunity for everybody who did not get a ticket to participate. So we're looking for volunteers that want to host a location for others to show up. And there is the opportunity for you to get an ng-conf t-shirt and other things like stickers and be able to watch the conference with other Angularians. So look to the website for more information about that. Be sure that you subscribe to the newsletter for information about that. And that's our big ng-Conf announcement for right now. CHUCK: Do you have a pick and a tip for us? JOE: I'm going to start with my tip which is to test your Angular code. WARD:[Chuckles] I'll think of that…CHUCK: That’s my tip too. JOE: The ability to test your Angular code is the reason I got in to Angular. I found Angular that it was testable and that was why I got in to Angular to begin with was because it was testable. And so you should test your Angular code. So that’s my tip. And for my pick, I am going to pick the YouTube channel Working with Lemons which is a group of people that do real-life versions of Disney music videos. So they have a bunch of cute kids that will act out and sing a real-life Disney musical song, and they have some little kids and some older kids, and they just produce a lot of really cute videos. And I think they are really enjoyable to watch. So, Working with Lemons, that's my pick. CHUCK: Awesome. How about you, Ward? WARD: Let’s see. I didn't get into Angular because of testing. I got into it because it just worked and it really was fast to develop in, and it just felt architecturally coherent to me. I have a feeling that testing had something to do that were driving that, but it wasn’t why I got into it. But I’ll agree with you Joe, that I think  discovering testing in your Angular code is a good thing. My pick though would be I've been doing more Gulp recently. And I think that’s worth learning. So start looking for resources on that. I know that John Papa is putting together a course on it, so that may be out in a few months. That will be worth looking at. I'm sure there are other resources that are worth looking at but Gulp has really been an eye opener for me because I'm coming to this frontend development world from the whole .NET world. I'm sure many of our listeners are. And it's kind of a revelation. And it's also interesting to see that tools like gulp are finding their way back into the .NET development world as they evolve to ASP VNext. So it's definitely something worth spending some time learning. CHUCK:Very cool. I'm going to have a pick here and that is LeanPub.com. It is where I'm writing my podcasting book. If you want to check it out, it's at leanpub.com/podcasting (oddly enough, that wasn’t taken). And so yeah, you can go pick it up. I'm going to have all kinds of information in there, not just technical stuff but how to grow and monetize your podcast; how to grow your audience; how to record. So there are some technical stuff in there. But a lot of the questions I get are more about kind of the softer skills; the less technical parts of the podcast. So anyway, I'll be putting all that in there. A lot of it is based on my own experience, but I’ve have talked to a few friends of mine who have been podcasting for a while and I either answer their questions or use them as case studies in the book. So I'm going to be working on that over the next few weeks. Also, if you go to pickuppodcasting.com, I'll have information there as well as to how to get signed up for the course. And you can either pick and choose the sessions you wanna go do or you can sign up for the entire thing. So that’s my pick. We'll wrap this up and we'll catch you all next week![This episode is sponsored by Mad Glory. You’ve been building software for a long time and sometimes it gets a little overwhelming; work piles up, hiring sucks, and it's hard to get projects out the door. Check out Mad Glory. They are a small shop with experience shipping big products. They're smart, dedicated, will augment your team, and work as hard as you do. Find them online at madglory.com or on Twitter at @madglory.]**[Hosting and bandwidth provided by The Blue Box Group. Check them out at bluebox.net]**[Bandwidth for this segment is provided by Cache Fly, the world’s fastest CDN. Deliver your content fast with Cache Fly. Visit cachefly.com to learn more.]**[Do you wanna have conversations with the Adventures in Angular crew and their guests? Do you wanna support the show? Now you can. Go to adventuresinangular.com/forum and sign up today!]