036 AiA Protractor with Julie Ralph

01:20 - Julie Ralph Introduction

02:47 - Finding Angular and the Team

04:50 - End-to-End Testing

WebDriver

08:46 - Making Scripting Easier with Protractor

10:57 - Grabbing By Model

11:27 - Framework Support

12:59 - What You Need to Know to Work with Protractor

Node.js
Debugging Knowledge

14:14 - Data Hydration for Tests

16:10 - Using Mock Modules

17:52 - When Should People Start Using Protractor?

23:21 - Using Protractor for Performance Testing

benchpress

25:06 - Writing End-to-End Tests

29:28 - Testing Stories

The PageObject Pattern
- [YouTube] Jim Lavin: Using Page Objects in AngularJS Protractor
Authentication User Scripts
Red Flag: Logic in Your End-to-End Tests

32:05 - Protractor 2.0?!

33:33 - Support for Angular 2

Transcript

JOE : Maybe John himself has like got a bug and he's frozen. WARD : Or he's got audio problems. But then, he should be typing something to say something. JOE : It might be a tumor. WARD : It's not a tumor! [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! Welcome to Episode 36 of the Adventures in Angular Podcast. This week our panel, we have Joe Eames. JOE: Hey, everybody! CHUCK: Ward Bell. WARD: Hello. CHUCK: John Papa. JOHN: Hey, everyone. CHUCK: I'm Charles Max Wood from devchat.tv. A quick reminder: if you're into Rails or if you wanna support the show, go checkout devchat.tv/kickstarter. This should come out like the last day of the campaign. We also have a special guest this week and that is Julie Ralph. JULIE: Hey, guys! CHUCK: Do you wanna introduce yourself really quickly, Julie? JOHN: Yeah, sure. My name is Julie. I am a Dev at Google. I work up in the Seattle office. And I work in the Angular team on testing. Specifically, I'm the author of Protractor, the end-to-end testing framework. And I also work on general code and continuous integration, health and developer productivity for Angular and teams using Angular, and teams using Angular at Google. WARD: What is that larger charter mean? Because that’s interesting. What you do outside of Protractor for productivity and health and all that? JULIE: That’s a good question. JOHN: Angular health sounds like… is Angular health like making sure that Igor and Misko get their exercises? JULIE: [Chuckles] So, there's a lot of setup and process that the Angular project itself has in terms of how it generates its own documentation and how it tests itself. And so I do a lot of helping out with how that gets run using Travis and then connecting to services like Sauce Labs and browser stack to get actual browser VMs, how we report results, how we make sure that the that go through get test results in a reasonable amount of time. And reducing flakiness is one of the really big things that we’re focusing on right now for whole setup. WARD: Wow. That’s noble. How did you… I don't wanna say “stumble in” because stumble in everything. How did you get into this game? Where did you come from and how did you find this role at Google? JULIE: I think “stumbling” would be fair. I've been at Google for about the past almost five years now. And I was working on one of the projects internally that was using Angular back in the 0.9, pretty early days before it got really big and a lot of people knew about it and knew how to use it. And so back then, it was really easy to go get the attention of Igor and Misko. And I was working on testing for this project and finding that the solutions back then for end-to-end testing which was Angular Scenario Runner, were really not having the full feature set that our team needed. And didn’t support a lot of the things that I saw in other tests at Google which were based on WebDriver and native events, and a lot more support for not having to specifically host files for testing on your server. So I went down and I talked with Misko and Igor and I said “Hey I would like to make this better. I’d like to make a more general solution for end-to-end testing.” And I think they said “sure” and thought I would forget about it pretty soon. But I was really interested and ended up working on it and has been able to just keep doing that. So, now, I work pretty much full time on Protractor and related projects. WARD: That’s an interesting trajectory; the very idea that you could sort of be inspired by a problem and then go pitch it and take over. Is common in the culture? JULIE: I think so. And I think I definitely got lucky that it worked out, that I'm able to be working on this full time. But Google is very much one code base, one engineering culture and everything is open to everyone. So if you see a problem somewhere, you definitely can go and say “hey, if I have the bandwidth to fix this, will you help me out with it?” And it's very, very supportive. WARD: Well, that brings us to Protractor itself. And so, those of us out here sort of know it has something to do with end-to-end. Those of us who have tried end-to-end in the past have felt burned several times. [Laughter] And think that that is just like it's hard enough to get anybody to test anything in the first place, and to deal with the DOM and the real thing, that's just going to be fraught with peril. I'll get around to it someday, maybe, but you've been out there talking Protractor to people, getting up. And I know our experience of fear, it has something has to be something you run into or dread or whatever. You have to have encountered this and feel that we might be missing an opportunity. So maybe you can tell us what it's like to kind of find that and address it. JULIE: Sure. So yeah, end-to-end testing is terrible in general. And I think one of my favorite things that someone said about Protractor was “hey, this is surprisingly painless.” And that's my goal was to make end-to-end testing surprisingly painless. So end-to-end testing shows a lot of symptoms of all sorts of errors that happens all throughout your application. So I think one of the problems is that it often gets blamed for problems all through the stack. For example, when you're developing some sort of project, you probably have some way to set up a local instance of it, so that you can mess with it on your own machine while you're developing without polluting the database somehow. if you have that set up really cleanly, and that's very modular, then you could use that same sort of system when you're doing your end-to-end tests, so that your tests don't go and pollute whatever database. But if you don't have that set up, it's going to be harder to setup your end-to-end test. So that's a bigger problem than just testing, but it's something that can easily show up when you're finally trying to write those end-to-end tests. But beyond just those issues, most end-to-end test, I would say that the industry standard for webpage tests right now is using WebDriver -- which is what Protractor does. So in the end, it's built on top of WebDriver. WebDriver is a tool that defines an API between tests and browsers, and then tries to implement those API actions, which are things like clicking on an element, getting the text from an element, etcetera. WebDriver is a standard for how those should be implemented and how all browsers should respond to them. And they tend to respond, like a browser would respond to a native event. So actually clicking on it as opposed to just triggering a click event, there's some subtleties in there that would make it actually act differently like a real user clicked on it. So Protractor is built on top of that. WebDriver has a limited API and often runs into issues where you get things like race conditions because the webpage is slow or something else happens. So what Protractor does is it's built specifically for Angular applications. And since we know more about a site, given that it’s based on Angular, then we know any generic page on the internet, we can do smarter things. So we have hooks inside Angular that Protractor uses to ask when is the page stable, and things like how could I find an element based on some binding… strings bound to a string, user for example. So we use those hooks to try to make testing more stable and less flaky. And then Protractor also has a full command line runner, and that helps with getting WebDriver setup and running tests and getting good output from tests. WARD: So help me clarify that. Because I'll tell you what, when I've used other tools, I usually end up sort of having to… I think you said it, but I wanna know. I'm trying to script it and one of the reasons I hate end-to-end is that my scripts don't last very long before they're all broken. But it's like trying to find the button with id=foo and blah, blah, blah. And what you're saying is that Protractor allows me to script things in Angular terms somehow? Is if that’s so, what are kinds of the things that make my scripting less brittle, more functionally focused, make it easier for me? JULIE: Exactly. So if you have a page in Angular, we know a lot about what your template looks like. Like, you probably have bindings using curly braces for the ng [?] directive and you probably have models in your forms using ng-model. So with Protractor, you can locate elements using either a string match for what the binding is or for what the model is. And this can be a lot more stable than using things like XPath selectors or CSS selectors that might change when you're just doing stylistic changes to your page. If you're changing what the ngModel is bound to, you're probably actually changing some significant functionality that merits going in and modifying your tests as well. JOHN: So if I heard you correctly, then what I could say, instead of finding an element or an id or anything like that [?], I could say “go get me the model that bounds this” or I could even… can I do that with like a click? For example, say, “call this method on a particular model”. JULIE: You can do it with model. You can’t actually do it with click right now. And we have had for a while, thoughts about adding more ways of getting elements that are bound to certain events – so, click and key press and those things. And we'll probably have a change that allows those selectors soon. And we're also thinking about what we wanna do in the future for when Angular evolves to have new syntax in Angular 2.0, how we wanna grab elements there. JOHN: Yeah, but today, when I use Protractor and [inaudible], I grab things by model, so I can set properties, you know, enter my username, enter my order number, things like that. But then I have to go find the element to run click the button to do a search, or click a button to do a save, for example. So is that still the model today with Angular 1.3, 1.4 ? [Inaudible] But I wanna hear your opinion on that first. JULIE: Yeah, that’s correct for now. JOHN: And then the second thing is I know the last time I went into this, it worked really, really well when I was writing Jasmine. [Inaudible] syntax for Jasmine with my tests to write the language for all my tests with Protractor. But I was at the time using Mocha quite a bit. And when I'm using Mocha, I seem to be struggling through with a lot more. Is there any preferred framework? Or does it matter what framework I use when I'm using Protractor? JULIE: So Protractor supports Jasmine and Mocha fairly well. And we also somewhat support Cucumber (although that’s mostly community contributions and there are several known issues.) And we actually have an arbitrary API for frameworks, so you can go in and as long as you can hook into our framework API, add whatever custom framework you would like. Most of our tests are in Jasmine and that is our correct primary use case. So we support both Jasmine 1.3 and Jasmine 2.1, which there's fairly significant differences between those. And we do have a migration guide you're interested in moving from 1.3 to 2.0. But a lot of work has been done with Jasmine for making sure that for example, stack traces give the same line numbers and time outs work properly. And we just don't have the bandwidth to do all that work for every framework. So I would say Jasmine is definitely the best supported, and Jasmine 2.0 would be your best bet right now and that Mocha is the next level of support there. JOHN: And the reason I kind of go down this road is that it's difficult when you get into these realms to know what are all the players I need to be aware of? We’ve mentioned WebDriver, Protractor, Jasmine or Mocha for example. Is there anything else somebody needs to learn about [inaudible] to kind of jump in here? JULIE: You need to be able to use Node. Protractor is a Node program, so having some familiarity with that is useful. And it's also worth noting that every test file that you give to Protractor will be interpreted via Node. So you can do things like pull out helpers and use Require to grab your helper files. Knowing about the browsers that you're testing on is also very helpful in terms of how you will debug and being able to use the developer tools. WARD: Yeah, how you can debug your end-to-end test. Is that what you mean? JULIE: Yeah. So being able to… you have a feature where you can pause in the middle of your tests, and then you could go and for example, on Chrome, open up the Chrome dev tools and look at your application from there. So general knowledge that you probably have from debugging when you're developing outside of end-to-end tests, but that's also very helpful. WARD: Got it. One of the things that… in all serious apps, I usually have to sort of navigate to the point of interest from the entry point. And that means, you know, I have to put some script that is going to get me from screen to screen, maybe I'm using one of the routers. And that can really go awry because I can lose track of where it is. Is Angular aware of the routers? Is there something that makes it easier to sort of pilot your way through to a place you wanna be? Or do you suggest that there's an alternative way to arrange your tests so you don't have that problem? JULIE: So I think the best thing to do, if possible, is to make it so that you can navigate very close to the state that you want in your application by just going to a certain URL. So that means that you're encoding a lot of important information using an Angular router or such. But I know that not all applications are set up that way. So you often do have situations where you have some sort of large before test block that will actually just be navigating to a certain location. And there is not really much that you can do about that if that’s how a user would have to get to that state that you're testing anyway. One thing that can also be helpful is I've seen a lot of tests where they're doing a lot of data hydration before every test, so that means something like I have to set up an account instead of a user before I can actually make my test run. And often, doing that through the UI is, first of all, it's going to be slow and it introduces more places where you might get flakiness, so that’s generally not the best way to do it. I think a good solution there is if you have an API, you can have Protractor just go ahead make an http call to your API to get your user set up. You don't have to go through the browser just because you can. WARD: Oh, that gets into sort of a more general question of like, often times, your app is going to do something that is either going to leave bad traces behind or invoke a service like charging a credit card that you really don't want it to do. So you're trying to get as close to the real thing as possible, but you're going to have to fake some things out in order to make it realistic. There are ways to do that in Protractor? How do I learn about those? JULIE: The primary way that we have to do this is using mock modules. So when you load an application -- which is an Angular page -- using Protractor, it actually has a step before Angular bootstraps itself, where Protractor will load in any mock modules that you specify in your tests. Which means that those can override the modules that exist on the Angular page. So for example, if you have a service which calls out to charge credit cards, you can override that service from your test without actually changing the website code at all. So that's mock modules. You can for that in our API documentation. And we have some example tests that are using that in the repos. WARD: And yet the rest of it would be the real app. I mean, the true end-to-end, but you would just be sort of swapping out that one little piece? JULIE: Exactly. WARD: Ah! JULIE: Another technique is kind of what I was referring to earlier though about having a good environment setup for development, where when you're manually poking around, you're not making some charges to a credit card, right? So you probably want a more general way to set up an environment that's not messing with important data. CHUCK: At what stage do you recommend people start using something like Protractor instead of you know getting in and writing their unit tests? JULIE: That's a great question. I think that there is a tendency to think that, “Oh, I've heard that test-driven development is great, so I'm going to write unit tests first -- which I love. And I wanna write end-to-end first, which I don't really think makes sense.” I think that a lot of the benefit of the end-to-end tests comes from replacing a manual script that you would have to go through to verify to yourself that, yeah, this site is working. So I think if you reach the point where you're doing some sort of manual verification that a page is working more than twice, it's probably about time to start writing that end-to-end script that will do that for you instead. I think that there's a lot of benefit to getting some sort of end-to-end test set up a really simple one, fairly early, once you can actually have a site and load up a page. Because then, you're kind of forced to have that good separation of environments when you're developing, so that you have a way to set up an environment that you can run in your end-to-end test against. And once you have that baked in from the beginning of your development process, it's a lot easier than trying to create one once you have a whole bunch of infrastructure already set up. So a really simple test like that will be something that maybe just goes to your homepage and verifies that there is a navigation bar and if the user is logged in, the user’s name exists. So, something really simple -- really small tests. But from that test passing, you know that your frontend is serving, you know that it's hooked up to your backend, however, you know that there's no terrible mistakes in your process. WARD: So imagine I did that. Which that sounds great, and by the way I think that’s how people should at least lay down the baseline for a unit test too because they wanna do something and I just say, “just get it so it works.” So imagine we did that and then we were able to hire you – which I know we can’t – and we said, “Hey, here's a page. I’d like to be able to write some tests over it.” How long would it take you, (like somebody who really knew it) to carve out a couple of tests that would just give me a good sense that that page was behaving the way I want to? How does that time compared to writing a battery of unit tests against the functionality that lay behind that page? JULIE: I think that how long does it take for a user to interact with your page – probably a couple of minutes. And ideally, when you're doing a Protractor test, it should be that time that time that it takes for a user to interact with the page, plus a little bit of time to go in and look up the template to see how you wanna locate those elements. So maybe multiply that time by a factor of ten or something. That's probably a bit optimistic, but I think that's kind of the goal for how simple writing these tests should be. WARD: I see. So if I had a one minute scenario, you're saying I could cover that scenario in ten minutes. I should be able to write a Protractor test for that scenario in ten minutes? I know that sounds aggressive. To me that would be fantastic. But you're saying it's at least order of magnitude around that? JULIE: Okay, so I think this is assuming that you have the basic infrastructure set up already. WARD: Right. Right. Once I've learned it and once I've learned Protractor, I'm not talking about learning that… but see I have the sense that it just so forbidding, that I'd be spending hours to do the simplest thing. And you're saying it doesn't have to be that bad? JULIE: Yeah. I think that a lot of that time also comes from debugging the test if it doesn’t work, right? So if you have a set up where you can pretty quickly run your test, you can use things like, in Jasmine, there's the ability to do a focus it block, which will just grab one file. And I believe in Mocha, it’s “it.only” to just run that one test. So while you're developing your test, you can just run that one over and over and make sure it's working. JOE : Which always have a commit hook that doesn’t let you check that in. JULIE: Yes. Definitely. [Chuckles] WARD: “And my test runs so fast when we have .only.” JULIE: [Chuckles] “Look, I've reduced test times [inaudible] one minute.” WARD: Exactly. JOHN: You know, I got to say I feel like an utter failure right now because ten minutes to write a one-minute scenario test, and I think what I have done in Protractor has been more like two to three hours [chuckles] writing the ones that I’ve had to go through. And usually, most my time is spent not only figuring out the templates and which things to actually grab, but also it also seems to me that there's a couple different ways to use Protractor to obtain the templates. Which syntax, which API, should I be using? Because just like Angular, there's a few different APIs to actually interact with different elements. JULIE: Yeah, that’s definitely true. And you can probably go through and just use CSS selectors for finding elements and have a pretty good time. I think that CSS selectors and finding elements by what they are bound to are the two most useful ones. And then ID -- Element ID -- is good if you have IDs already in your page or if there's some things that you already know were going to be unique and just want a very certain way of grabbing that one unique... JOHN: Yeah. Maybe some of the reason my team had issues with that is because we're trying to do it the Angular way. So we almost would say, “go find it by models” when sometimes, maybe just getting an ID is easier. JULIE: There's nothing wrong with that. JOHN: Yeah. So just like a normal developer, I usually try to make the framework do what I wanted and it's my will. I've got a related question where is this bad? Is this good? Is this something that you see a lot where I'm using Protractor to actually crank up my website and a little bit of performance testing? Obviously, I take off the startup time of [inaudible] WebDriver, but is that something you’ve seen people do out there? JULIE: Yeah. I think it depends on what type of performance testing you're looking at. So WebDriver introduces a lot of latency in between when you request an action. So for example, let's say click action and when that action actually occurs. So if you're trying to do sort of really small benchmarks in your browser, where you're looking at tens and hundreds of millisecond level performance, that's probably going to get swamped by the latency that WebDriver is introducing. And you're probably going to get pretty noisy data that’s not super useful. On the other hand, if you're kind of looking at how long does it take a user to navigate here and fill some stuff out, you know, is it ten seconds or twenty seconds? Then you're probably getting some fairly useful information in terms of how long it takes your page to load and how long it takes for requests to go through your backend and come back and log you on, for example. The Angular team is working on a project called BenchPress for doing these very small micro benchmarking. And that actually uses Protractor essentially just to open up the browser and then report information back from it. So it's using it just to get an instance of the browser and then the actual performance is all done via JavaScript on the page itself. WARD: You know, one of the things that we talked about is that there tends to be a lot more set up, just to get to where you wanna point the test, than it would be in normal unit and integration tests. And I would expect that. The more of an integration test you have, the more set up there is, usually. And now, you introduce these latencies with the test is running over here and it has to talk to the browser over there. So there’s the sort of usual rule when you're in Jasmine or Mocha that you have one expectation per it – one expectation per test. I have the sense that that’s not terribly efficient. Is there a different style of writing tests when you're writing end-to-end tests? And if so, how do I learn about that? JULIE: I think a lot of that is up to your team in exactly how you prefer to write things and how important that the time the test suite takes is to you, versus how important it is, that each spec be completely hermetic, for example. Some teams really care about being able to run each spec out of context of everything else. And some teams are okay with maybe a file being able to run out of context of the other files, but each individual test inside the file might depend on things that come before it. These are hard questions to answer. And one of the things that we've been working on internally to Google, is a sort of style guide with suggestions for how you might setup and write end-to-end test with Protractor. And we would like to make that available more widely. And also available to comment on and change, because I think that there's a lot of teams out there with a lot of good experience. And honestly, this is one of the areas where I'm writing the tools and I work with people who use the tools, but probably the heavy users are the best people to answer that. WARD: That would be so good. You know what, it would be kind of good to have a play by play of that. Just watching somebody -- two people at work -- trying to build some end-to-end tests and sort of seeing what the motions are. It just feels to me that the mechanics of doing that seem like they would be different than what I'm used to going through when I'm writing unit tests. I don't know that that's true, but it just feels different. And that would be great to have. (Just a suggestion for you.) Given that I'm talking about this discrepancy, what kinds of things are great for end-to-end tests? And what are… what should you just leave for different kinds of tests?” Where would you say that boundary is? JULIE: I think in general, if you can verify a behavior in a smaller test, that’s probably better. So by “smaller test,” I mean, a unit test or maybe some sort of functional test, where if you're testing your back ends, you just take your API directly, you don't have to test everything all the way through the browser UI. So if you're testing business logic in your application depending on how I fill out this form, when do I get errors and when do I not get errors for every single corner case, that's definitely unit test style behavior. Do you wanna have one end-to-end test that looks at, “Hey, if I get an error, does the user get any error sort of red bar error message?” Yeah, I think that’s more appropriate for an end-to-end. So not worrying about corner cases and business logic very much, but looking at a user script -- how would a user actually interact with the page and does it work as expected? CHUCK: My experience with end-to-end tesst has been that usually, there's been some process that’s critical to the application running. And so you want to test at least a happy path on that, just to make sure that, you know, for example, people can place an order that credit cards gets processed as much as you can test that anyway. So you know, if you're using some payment processor and they have a sandbox, then you might have it either run all the way to the sandbox and back. Or you may mock that part out and just to make sure that it's making the right calls. But it's that kind of stuff where testing is a game on return on investment. And since unit tests and integration tests are much easier to write and you can get a lot of value out of those with not a lot of effort., and then you decide where you're going to get payoff on the acceptance test or the end-to-end tests is my experience. That's where you test the critical paths to make sure that they work because without it, you're up a creek. JULIE: Yeah, I agree with that. WARD: Julie, are there some case study or you've seen somebody using Protractor on a project that was very effective? And can you sort of describe what kinds of tests they were using there… what they asked what those test to do for them? JULIE: Yeah. So I think we've got some internal teams that have fairly good testing stories. I think that the big pieces of advice are using page objects to organize your tests. So for those who aren't familiar with them, page object is pretty much just a pattern for writing an end-to-end test, that says that you should have a helper file for each view of your website that lists how to find the elements and simple actions on them. So for a login forum, it would probably have a method to find the username, find the password and actually fill it out. And the idea is that then your test uses that page object helper file, so that your test file looks really clean and your it [inaudible] will have a method that’s like “on my login page.login” pass in the user name, pass in the password. Done. So that your test files are very descriptive. So I think heavy use of the page object pattern is one thing that really helps. And then the types of things that are tested are, like what I said earlier, critical user stories, making sure that users can log in. There are different levels of users in this application, so making sure that the user has the right authentications to see the pages that they are supposed to see and not see the pages that they're not supposed to see. And these are user scripts that are fairly easy to test and that they don't take forever. It's not filling out a two hundred line form and testing every permutation of that. But they are really important for the application that those happen correctly. It's really important that someone with permission to see the account levels settings can see them and the ones without it can’t. WARD: Yeah, that makes sense. Do you have any horror stories for us? Everybody loves a horror story. [Laughter] JULIE: Nothing specific, but I've a lot of people trying to test all sorts of permutations of forms. So things that I think really are really better in unit tests. I think a really big red flag is if you have logic in your end-to-end tests. So for example, if you have a bunch of if statements or if you have a for loop in your end to end test, you really wanna take a look at that and make sure that that's not something you should be testing in a unit test. WARD: So what's happening in Protractor? Are there new releases coming down? And then I wanna ask you about how Protractor relates to version 1.x versus 2.0. JULIE: I'm really glad you asked. We will be doing a Protractor 2.0 release version to that. This is really not exciting. It's a very small change, but we're introducing a breaking change that we think will probably affect a decent number of users. So in respect to semantic versioning, we're doing a 2.0 release. This breaking change is basically changing the way that locating elements returns a promise. Right now, if you try to locate an element, that object which we call an “element finder” is a promise which resolve to itself. And that's not allowed to by the new promise spec and it was causing problems in a lot of areas. So we've removed that. It doesn’t remove any functionality but I think it might break several users, so that’s why we've made this version 2.0. So look for that later today. CHUCK: Just be clear, what you're saying is “we're fixing promise functionality 2.0 in Protractor” doesn’t correspond in anyway to 2.0 in Angular? JULIE: That’s true. So yeah, this is just a major version bump for semantic versioning. It has nothing to do with Angular 2.0 or Jasmine 2.0 or version 2.0 of any other project. We are, however, working on support from Angular 2.0. And I think that the goal this is to make the process transition as seamless as possible, so that if you have an application that you're upgrading in the future from Angular 1.x to 2.0, you can keep your end-to-end tests pretty similar and use that to help check that everything in the migration has gone forward. Again, this is still work in progress. We don't know exactly what this will look like. But in the same way that there's hooks in Angular 1.0 that Protractor uses to help stabilize your tests and find elements, there will be hooks in Angular 2.0 that Protractor uses. WARD: So you're pretty involved in the design process for 2.0 to make sure that it has that testability built into it. JULIE: Yeah. And if you go and look at the Angular 2.0 GitHub page, we've got an issue tracking list and you can follow along if you're interested. CHUCK: Very cool. And I think we are about at the end of the time that we usually go to, in fact, we've gone a little beyond it. So, let’s go ahead and get to the picks. John, do you wanna start us off with the picks? JOHN: Sure. I guess I can do that. So one of my picks in the theme of testing is there’s this cool library out there written by some anonymous author named bardjs. It's my technical tip. I am well-known for not enjoying writing tests at all and bardjs is a nice test helper library which helps you write tests with much less friction using Jasmine and Mocha against Angular. And it's actually written by Ward Bell. So it's my pick is if you don't know what Bard is, once you start writing tests, start writing them about it, then go check out bardjs and see how much time it saves you because it's pretty darn awesome. CHUCK: Joe Eames doesn’t like tests either. JOE : No, I'm not really a big fan of tests. WARD: [Chuckles] He said sarcastically as he has courses on the subject and have strong opinions. JOHN: [Chuckles] JOE : You know, I almost feel like angry that Ward and you guys are doing the testing course on Angular. Like, that should have been my course. WARD: well, we're going to send you to the anger management course. [Laughter] JOE : No, that’s totally awesome that you guys are doing a Pluralsight. Is it out yet or are you guys still building it? WARD: Now you're just kicking us in the tail to build it. JOE : Get it done, guys. Come on. JOHN: Ward and I are going through great pains to make sure it's really, really awesome, so it's still coming up. But we do have a play by play coming out, which is a two-hour of video Ward and I struggling mightily to write tests right in front of your eyes. JOE : Oh, that’s awesome. WARD: Yeah, it was fun. We usually have fun and that’s part of the play by play is about we're trying to bring the fun back into this. And I think Julie is going to bring the fun into end-to-end testing -- if there's fun to be had. JULIE: I don't know, I promised a “surprising painlessness”, not fun. WARD: Oh! Painless is more fun than pain. JOHN: Well, see, I was thinking surprisingly painless end-to-end testing, you can [inaudible]. JOE : Ward, that statement is not at all true according to a movie that recently came out. WARD: [Chuckles] Oh, goodness. CHUCK: All right. Ward, picks? WARD: I have a pick. I read an article recently about teaching and what makes for good teachers and what makes… how do we know that how does that relate to teachers in our schools are recognized. And you know, are they even recognized for the things that seem to be working? And so this is an article in the Guardian, and in particular, it focuses on this guy named Doug Lemov who video tapes teachers who… first they went out and they sort of said “forget what everybody's saying about these teachers,” you know, where are the dramatic differences happening, especially in schools with poor performing kids. And then let’s just go video tape them. Let’s not just talk about the wording; let’s those videotape it of those teachers and see what they're doing. And see what kinds of things that make them different in the classroom? And this has led to a fascinating book that seems to be getting some traction out there by this guy called Doug Lemov. And his book, which I will put in the link notes, that is my tip. Go read that because what I'm thinking is that that will also help any of us who have to share information with our colleagues or do workshops. You know, it's not just for kids; it's for us. At least that’s what I thought. So I'll put that in the notes. CHUCK: Awesome. Joe, are you ready with the pick? JOE: I am. So as I mentioned on a previous show, I went to a board gaming convention last weekend which was completely awesome way to take a vacation and spend three days all day long playing board games. And of the board games that I've played was called Colt Express, which actually has these little like cut out trains and you have little guys who are on the trains and you're trying to rob the train and before the three other people that you're playing against rob the train. And it's super fun. Super easy to learn. And because they have little diagrams and little cut out figures, it's actually really fun to watch and play and get to punch and shoot the other people -- which was quite enjoyable. [Chuckles] So it's just a great game. It's just very unique, you know, there's not like an actual board but it's not quite miniatures. It's actually like a train; a real, cut out train that you have your little fingers on and they move around on the train. It's super fun. So I'm going to pick Colt Express. CHUCK: Very cool. I’ve just started getting into ng-book. And I've really been enjoying it. I've kind of dabbled in Angular and built stuff in Angular on my own, but I wanted something that was a little bit more formalized. And it's pretty good, so I'm just going to go ahead and just pick that. And I guess that's a pro tip as well. JOHN: I think what’s cool about the ng-book too is when I first bought ng-book, I did it through like the Amazon Kindle reader option, but I think the better way to go is actually to go right to their website. Because the way I understand it is if you go right to their website to buy ng-book, you get all the updates. So anytime new version of Angular comes out, you get a new version as well. WARD: I can confirm that. I've been getting regular updates since I’ve bought the first version of it, six or eight months ago. JOHN: That’s awesome. So yeah, don't make a mistake like I did, and buy it off Amazon. WARD: Yeah. Go direct. Go to the source. CHUCK: [Chuckles] Nice. All right, Julie, do you have a pick or you can give us a couple of picks if you got them. JULIE: Yeah, I've got two quick things. So the first is in the Chrome DevTools State of the Union is out. The video is not up yet but the annotated slide deck is. And the video should be out probably by the time you're hearing this podcast. And so that's a really nice way to you know, see an overview of new features that you might not have noticed or tried out. And they are doing a lot of really cool stuff. So DevTools State of the Union. And then the second thing is I believe that when this comes out, it will be the first day of spring. And I did send digital spring cleaning, which made me super happy. So I went through and I unsubscribed from old mailing lists, and I cleaned up the GitHub issues and I deleted things I didn't care about. And it's great. And I think we spend a lot of time accumulating things that are giving us notifications of things that we're following, and sometimes you just need to go and purge out the old stuff you don't care about, so you can focus on the important things. So go do some digital spring cleaning. CHUCK: Awesome. WARD: Wow, that’s a frightening prospect, man. You should see my garage. [Laughter] CHUCK: And his digital garage. JULIE: You should see my inbox. WARD: [Laughs] Oh, you subscribed to inbox three thousand like I do? Well, I, for one wanna say that I am so glad you came on, Julie. I've been really looking forward to the show, part because I like your work and the way you present, and part because I think that this end-to-end stuff is so scary and you make it seem less scary to me. JULIE: Thank you. That is the goal and we definitely hope to keep making it even better. CHUCK: All right. Well, that's awesome. Thanks for coming, Julie. JULIE: Well, thank you so much for having me![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!]**