Discover Protractor Automation – End to End Testing for AngularJS (Transcript)

Below is the full transcript from my awesome TestTalks interview with Nate Taylor author of the new PluralSight course Introduction to Protractor

Joe: Hey, Nate, welcome to Test Talks.

Nate: Thanks, Joe.

Joe: Before we get started, could you just tell us a little bit more about yourself?

Nate: Yeah, so I've been doing software development professionally for about 15 years now. I started doing C++, Windows app in C++. I moved on from there to doing wind forms and dot net. And then, honestly, it's been about the last maybe five years that I've actually moved onto the web and started doing web applications.

Joe: So what made you get up one morning and say, “Hmm, I think going to do a Pluralsight course on Protractor.”

Nate: So it's a little bit longer of a story than that, I guess. I like speaking at conferences. I spoke at a conference here in the Midwest called KCDC a couple years ago, last year, I guess. And one of the listeners, one of the members in the audience, contacted me afterwards and said “Hey, I really liked your talk. I think you'd be a good Pluralsight author. Have you ever thought of doing that?” And at the time, I thought, “Well, they go find people. I don't get an audition or whatever.”

I actually knew Corey House through speaking at some other engagements and reached out to him. He got me set up with Pluralsight, went through the audition process. Protractor was actually my second course. My first course was TDD as a Design Tool.

I wrapped up the first course. And we were playing around with Protractor at work and I thought “Man, this is a really great tool that I don't think a lot of people know about.” And so I just pitched it to them as, “Hey, this is a course I'd like to do,” and they jumped all over it. So that's how that came about.

Joe: I think it's awesome because I think there is so little information on Protractor. So when I saw this on Pluralsight show up as one of the new releases, I was really excited about it. So in a nutshell, can you tell us what Protractor is?

Nate: Yeah, I've been thinking about this because I'm taking the Pluralsight course on the road, and am doing a couple of conferences with it. And I have less time, obviously. The analogy that comes up in my mind is robot users. Because it sounds kind of cool and it sounds a little bit more exciting than just automated testing.

But you get to write scripts in JavaScript just like you would in any other Jasmine test or Mocha test. And Protractor is a layer that sits on top of Selenium. So it runs Selenium in the background, but it gets you all sorts of really cool hooks into your AngularJs application.

So you can start grabbing your data bindings and you can start using some of the Angular goodness like ng-repeats and things like that. And can grab those elements by the Angular semantics and you can add to them, you can read from them, you can verify that your page has the right data. And it does it whether you're sitting there or not. It just runs when you tell it to. So that's pretty much a nutshell of what Protractor is.

Joe: Very cool. So can you give me an example of why or when I would use Protractor? For example, say someone has an existing Selenium framework that uses Java, at what point would you think it would make sense for them to look into using Protractor?

Nate: I think the best case for Protractor is if you have an Angular front-end, that's where it really seems to really take off because it has the hooks end for waiting. It can be smart and wait and know that I'm still loading data. And until Angular is done loading that data, there is no point in me trying to click a button that might not be there yet, or to enter text into a field that might not be there yet.

So once you combine Protractor with Angular, that's where the two really start to shine. And as far as use cases, what we've tried to do with it is really using it a lot as a regression tool. We have an application that has customers that create jobs and then get invoices on those jobs. And so we want to make sure that no mater what we do in the next block of code, in the next iteration, we can still create customers. We can still create jobs, and we can still make sure that customer gets invoiced on their job.

Joe: Awesome. I think what you've really highlighted there is a huge win, actually, is the built in wait mechanism that Protractor has. If you're doing normal Selenium, you have to sometimes explicitly say “wait for this to be visible” or “wait for this to be enabled.” It sounds with Protractor, it just knows Angular JS automatically when something's loaded. Is that correct?

Nate: Yeah, so it will wait for Angular. And you can tell it. You can break down or dive down into the Selenium web driver and you can tell it, “Browser, wait four seconds” or whatever it is.

It also knows, “Hey, Angular is running a service here and it's waiting on the return of that service before it can populate this data. So I'm gonna wait until that data comes back. That page is loaded now, and so now I can run my code.” And it really was one of the greatest things, I think, when I started playing with it. I remember playing with Visual Test in 2000. And that was for a Windows client application. And that thing was just horrible.

For the time, I'm sure it was great. But it was one of those things where you had to wait for the page to load. You had to make sure that the window was positioned at a certain X and Y coordinate or all the clicks were going to be off.

Protractor solves a lot of those programs for us. So we don't have to write a bunch of complicated code to make sure we're authenticated, or that the page is loaded, or that the things are visible. It'll wait for that and you can use promises, like normal JavaScript. You can queue things up and then once that promise hits, now I know that the data's there and so I'm gonna go.

So for example, in our application, we have a custom loading circle that comes up when you're doing a data intensive action, saving it to the database or whatever. And all that really is is a CSS class applied to the top div. And so we could wait until that class was no longer on the element and it would wait, and as soon as that class disappeared, my test would take off and go to town.

Really, the reliability issues were more of how good or bad we wrote our test

Joe: Sounds awesome. How many test scripts do you have, and how reliable have you found the waiting mechanism to be?

Nate: We don't have a bunch of test cases right now, or test scripts right now, with Protractor. Maybe on the order of a couple dozen. I found the wait to be pretty reliable in one situation.

So originally when we were working on our app, we tried to manually bootstrap Angular and kick it off ourselves. That one caused a little bit of problems with waiting. And to be fair, the Protractor docs even say, “If you're doing Angular initialization this way, here are some things you might have to watch out for, and here's some ways to handle it.”

Once we realized that we actually didn't need to do our initialization that way, and we could just put the ng app on the body element and it would initialize normally, we really haven't had any problems with it waiting. It did a pretty good job.

Really, the reliability issues were more of how good or bad we wrote our test. So sometimes we expected records to be there that we hadn't yet added or we had deleted in another test. And so that's where we ran into a bulk of our reliability issues. It was more developer issues than tooling issues.

Joe: In your Pluralsight course, Introduction to Protractor, what do you recommend people know before they take this course? What, at a minimum, do you think someone should know before they even try to tackle Protractor?

Nate: Yeah, that's a good question. I think probably a good thing to know is to have at least some familiarity with Jasmine or Mocha. They're similar enough in terms of JavaScript testing libraries, that if you know one, you're probably pretty familiar with the other. I don't go into a lot of detail on how to write a test or what the syntax is doing. It's assumed that you'll know that. So a corollary of that is that you have, not necessarily an even good JavaScript knowledge, but just some JavaScript knowledge.

Because again, we're not gonna spend time trying to talk about why I'm putting a semicolon here, or why I'm structuring the code this way. It's much more focusing on Protractors. If you've done maybe a little bit more than just basic j-query dom selectors, and you've looked at and have at least a grasp of what Jasmine syntax is, I think you'd be pretty good to go on Protractor. On the course, anyway.

Joe: For someone that's really new to Protractor, they might not be familiar with Jasmine or Mocha. How do they behave in the Protractor ecosystem, what do they do?

Nate: Sure. So I come from, like I said, a C++ background, a dot net background. So a lot of times, I try to draw analogies between libraries. So in the Java world, in the dot net world, we have X-unit. So you've got J-unit in Java, and N-unit in dot net. Those are libraries that you will write your tests in. You'll use their syntax, and a lot of times, it'll be in attribute, in dot net, or whatever. So Jasmine and Mocha are JavaScript testing libraries or testing frameworks. And you set it up, your test cases will say “describe.” That's the key word. So you say “describe.” You give it a string of what you're describing.

So one of my tests might be “when a user is logging in.” That might be my describe block. So that's going to say, “Everything that occurs in this block of code is going to be dealing with when a user is logging in.” And Jasmine will take that and say, “That's a test block.” And then underneath that, there will be several test cases.

So I might say, “When a user's logging in, make sure that the username's entered, make sure that the password's entered, make sure that it's the right password, make sure that they click the button.”

All those things will be individual IT blocks in both Jasmine and Mocha. And those libraries will then execute that code. So it'll read the JavaScript and it'll say, “I know what to do now.” And so what Angular does with that then, is that's how you're defining your spec. So you'll say, “Here's my describe block. We're gonna try and add a new event. We're gonna try and add a new concert in our system.”

So you would say, “Describe when adding a new concert.” And in your individual IT blocks, you would say, “Find the element whose binding is concert name or event name, and type in this text.” And so Protractor's going to read that script using Jasmine or Mocha, and it's going to say, “I know where this text box is.” I have the text box.

The next command is, “Send some keys to the text box.” So Protractor will then send input to that text box and just process your script that way. You can think of it almost like a DSL that Protractor uses when testing, and it really just tells it how to run the test and what each test case is.

Joe: So if someone's familiar with BDD, it's like a BDD framework or a test runner?

Nate: Yeah, absolutely, very much. I think they both try to give you that option, based on how you set it up. But yeah, it's a very similar mind-set. It's honestly one of the things I love about Protractor. I'm writing Jasmine all day, every day to write my unit tests. So I didn't have to go learn a Protractor scripting language or a Protractor framework. It was, “Oh, you're already using Jasmine? All right. Bring it in and we'll just run Protractor on top of it.”

Joe: Awesome. So I have very limited experience with Jasmine, but if I understand it correctly, as you're writing your unit tests, tests can be running in the background somehow?

Nate: Yeah, so with JavaScript, I will have basically either a gulp or a grunt build going. And so with Angular, they have their own test runner called Karma. So I'll just run Karma and just have it watch my files. And every time I make a change, it just runs whatever test it needs to run, whether I've got that limited down or not. So the same thing can be said with Protractor, as well.

You can have Protractor just running and watching for those tests. My use case, the way we've typically used it, is I don't let Protractor just sit there and run. I do it more at a, “Okay, my feature is done. Let me run all the Protractor tests and make sure I didn't break anything.” So it's more of a one time thing, whereas my unit test would be continually running.

I would argue you need to be doing TDD for your unit test

Joe: For someone that's hearing TDD, BDD, unit testing, end-to-end, where does Protractor fall? Is this a unit testing tool? Is this an end-to-end testing tool?

Nate: I look at it as if we go from left to right. So on the left hand side, we have unit tests. I would argue you need to be doing TDD for your unit test. And then on the right hand side, you have user acceptance testing. And that might be all the way to the point of your customer is actually clicking through or using the application and they're running their test cases.

So if that's the spectrum, Protractor's gonna fit somewhere in the middle or towards the right hand side. So you're going to write your unit tests that handle specific cases, often dealing with specific functions or specific lines of code. Then what we normally do as developers, or at least my experience with working with developers, is we'll develop our feature.

And as we're getting ready to commit it to the main line or issue a pull request, we'll run through it and try to do a bunch of test cases. Let me make sure that the button's enabled when it's supposed to be, or disabled when it's supposed to be. Let me make sure I can't click on it when it's disabled. And that's a great time to actually be writing Protractor tests because not only am I going to run through those tests, but I'm going to create a pull request, and somebody on my team is going to volunteer to take on the responsibility of reviewing my code and making sure it functions. And if I can push up a suite of Protractor tests that say, “Hey, here's all the tests I thought of,” that frees their mind a little bit.

They can run that suite and they go, “Yeah, those all passed,” but that gives me an idea, “I need to test these other things that your test case didn't cover.” I want to wait until the feature's a little bit more complete, a little bit more mature, before I write it because it's dealing with the UI. And so a lot of times that's going to change and be a little bit more nebulous than my individual lines of code.

So I wouldn't do it too early on, but definitely as you're getting ready to issue a pull request or as you're ready to commit to the main line, run them again as you're getting near release cycles. Whether that's at the end of the day, or at the end of a sprint, or at the end of a milestone, wherever that might be. That's where I see Protractor fitting in. So there's the phase where you want to write the test, and then there's the phrase where you want to make sure you run the test before it gets out to the customer or something along those lines.

It's only as intelligent as we make it.

Joe: So it kind of emulates as a real user would use your application almost.

Nate: Yeah. I talk about it a little bit in the course, too, what always frustrated me about testing is I get bored easily. And so if I have to test something where I have to go in and I have to see, “I know the customer name can be 100 characters, what happens if I type 101? What happens if I type 99? What happens if I type all numbers? What happens if I type all letters? What happens if I do all spaces?” I might do that once or twice, but if I'm gonna do that a third or a fourth or a tenth time, I'm not going to cover all those test cases. I'm just not.

It seems like these first two or three worked, what are the chances that the others broke? But that's a really bad attitude because there is a possibility that they broke. And so that's where I see Protractor really shining is, it's going to run that test the exact same way 100% of the time. So if I tell it, “Hey, here's the 15 checks you have to do on customer name,” it's going to do all 15.

I don't have to worry about something cool happening on Facebook and now one of my developers is reading Facebook or surfing Reddit or whatever, instead of doing the test cases. Protractor's just going to be there doing it.

So it does kind of act like a user, but it's not an intelligent user, right? It's only as intelligent as we make it. So it's definitely not a replacement for UAT testing, it's really more of a safety net. It can give you a boost of confidence, but I don't think it's ever gonna replace having a real user click through and test the application.

Joe: In your experience, this is a common issue with any type of test automation, is data setup. Does Protractor have any extra functionality that helps you, say you need to have a customer or user already in the system? You know, create data for your test?

Nate: Yeah, so there's a couple ways you can do that. I guess the one thought is on Protractor, you're interacting with your application strictly through the UI. So back in my server days, I could go in, and in my set-up or my before blocks, I could load a bunch of data into the database however I wanted. And at the end, I could pull it all out or make sure it was reset or whatever. And you don't really have that luxury with Protractor, because it's only coming in through the UI.

So in order to really test that, you have to have a way in the UI to set up the data that you want. So if you want to add a customer, you can go through and see if that customer's there, and then add it if it's not. But it does provide the normal “before each.” So before every test case runs, run this block of code, and after the test case runs, run this code.

So you could do some things in there where you get some initialization going and you get some initial values plugged into the right places. Especially if you're going to be sitting on a page and running a bunch of tests, you can set the form up the way you want and then check different things. Like, “Hey, check that the error shows that you entered an invalid zip code. Or check that the phone number was wrong or something along those lines.”

The other thing Protractor offers in terms of setup – and this goes a little bit more towards the entire app setup I guess – is it has the ability to configure a before launch kind of thing, or a “run this first” kind of setup. So what often this will be used for is if you want to test a post off site, you could do that there and put your login code there.

In my Pluralsight course, what I used it for was to actually make sure that my browser was full screen resolution, just to give people the best view of the website rather than having it whatever Chrome pops up in. So in that course, there's an example of how to do some code before any of your tests run. Like I said, I use it to make sure the browser was the right size, but you can do anything there. You can set up a login or maybe you can make some service calls to get data in the right configuration before you run it.

Joe: So it's like a before scenario or before story?

Nate: Yeah, so there's setups for each individual test case. Jasmine provides that with the before each. But then Protractor itself also provides a, “Hey, we're getting ready to run this suite of tests. I need to run my init [SP] script first” kind of thing.

Joe: Cool. So Protractor, it's almost like a wrap around top of Selenium. Is that how it works?

Nate: Yeah, it is. And in fact, I think you can get to all or almost all of Selenium, even with Protractor. Selenium's got the locators, right? So you can locate by CSS or by ID. Protractor can access those as well, it just adds some additional ones. So it adds things like, by binding – which is how you're binding your Angular data – or by model name, or by repeater, or by options, which are all Angular-specific terminology.

But you can get to the same ones that Selenium has, and then you can even define your own locator. So if you have a custom way that you've always done buttons, you can define your own locator so that it would always grab the buttons. And all of that is normal Selenium stuff, it's just the Protractor team made it a little bit easier for doing that with some of the Angular directives.

Joe: So for the Angular-specific directives, like the by binding, how would that help someone that's trying to automate something? Does that allow you to get certain functionality that would be very difficult to get at if you had to use just a CSS, or an x-path, or and ID, or a name?

Nate: I don't know that it's much more difficult. I think you could do it. I think it's a little bit clearer because you're using the same idioms that you're using to test as you are when you're developing.

So if you have your Angular application and you're going to iterate over a list and create a bunch of LIs on your website, you're going to use an ng-repeat in your HTML page. And it's going to be an ng-repeat my items end items or whatever it is. And you're already in that mindset because that's just how the Angular world works, basically. You're thinking like Angular.

And so Protractor, instead of saying, “I know I need the third LI and it needs to be the keyword blue,” and so you'd have to do that through x-path or through some kind of, “Okay, find me all the LIs, now let me iterate over them.” It provides you the ability to say, “I need the one that has the ng-repeater that is my items end items, and I need the third element underneath there.”

And it's going to return you that LI for it. So I don't know that it's necessarily way simpler, but it's the next evolution. It's just a little bit easier than what it would have been with Selenium.

Joe: Awesome. So it was my understanding until I just had this thought now as you're speaking. Protractor was just for Angular-JS, but since you can actually use Selenium under the covers anyway, I guess it's not just for Angular-JS. You could start using it, creating a framework against an Angular-JS application, but it sounds like you could use normal Selenium just to test any application. It doesn't have to be Angular-JS.

Nate: Yeah, I think that's true. I think they recommend that you don't. Because of the overhead of if you don't have Angular involved then don't bring in the unnecessary overhead. But yeah, since you can drop down, I think the key word is browser. So browser-dot will get you to the web driver manager and get you all the Selenium stuff.

So you can do that. And by all means, if you're a wiz-kid on Selenium, which I am not, and you know way to do things that maybe Protractor doesn't support, you can still test part of your application with Protractor, and using Protractor drop down into Selenium and do things that aren't as apparent in Protractor in another part of your application.

Joe: Would you see this more as a developer activity or a QA activity? Who writes Protractor scripts, typically, in your experience?

Nate: So that's something that I've gone back and forth on. Originally, we had this really sharp intern at our company. I showed him Protractor one time. I spun it up. I think I did something really simple like “make sure there's 20 items in this list.” Just as a proof of concept, I committed it, pushed it up, and then I walked it in and was like, “Hey, check this out. It's really cool.” And he just latched onto that and he was all over it. And he went home that weekend. He wrote a bunch of Protractor tests. And he's a real quiet guy, but I got him to do a presentation for our company. We have lighting talks at our company a lot of times. So I got him to do that. And a lot of the developers thought it was really cool.

And before that meeting, I was thinking, “This would be something great that if we have QA people that have an interest in scripting or have done JavaScript in the past, this could be a great tool for them.” But just seeing all the developers so excited about it, it seemed like it really could be for anyone, as long as they have that kind of ability to write scripts.

So I think probably what would happen, is the developers who write Protractor tests would write some subset of tests that the QA guys would come along and say, “Oh, man. You guys missed 50 or 75% of the use cases. Let me write those for you.” And we as developers would probably be amazed at what we missed, but it would be more of a collaborative thing. Where I wrote some test cases just to get the ball rolling. But QA could definitely come in and say, “Yeah, you wrote some, but that's not gonna be enough for me to have any confidence that this latest build didn't break anything.”

Joe: It sounds like if your developers are already using Jasmine for the unit tests, it seems like there would be an easy transition for them to start using maybe some Protractor end-to-end test in their work flows.

Nate: Yeah, absolutely.

Joe: Do you know if Protractor handles any performance testing?

Nate: Yeah, I haven't had a chance to look at it, but somebody actually just sent me a link. There's a Protractor performance package that you can bring in and it'll run through and take metrics while you're doing your Protractor tests. So that's out there. Like all things JavaScript, you can check it out on npm-js.org. They offer the npm package manager. But I haven't had a chance to actually play with it and see what all it's doing, and see how good or bad it is.

Joe: For someone to get started with Protractor, they do need node-JS. Is that correct?

Nate: Yeah, and primarily for the package management aspect, it'll just be a lot easier. And so the course on Pluralsight, it's actually using mean-JS. So the Mongo Express Angular Node Stack. But yeah, if you just go out to node-JS and download that, then you'll get access to their package manager and you'll pretty much be good to go at that point.

Joe: If I remember correctly, in your Introduction to Protractor course, you actually show how to set up your machine in order to get ready for your first test.

Nate: Yeah, I went through that. That was a learning experience from my first course, TD as a Design Tool. I skipped some steps because I already had Mongo running on my machine, and so I just skipped some steps. And that was some of the feedback, like, “Well, I got to this point and I don't know what to do now.” And I was like, “Oh, yeah. I didn't actually tell you that you needed to install that library or whatever.” The second time around, I corrected it at the expense of the guys that watched the first course.

Joe: That brings up a question in my mind now. Since you've released this course, it's been like a month or so, have you got any common questions asking the same thing in an email, like how come you didn't include this, or does Protractor handle that? Any of those types of questions?

Nate: Yeah, I've gotten a few on the discussion page. One person had a question where they might have different users that are hitting their site, or different roles, perhaps, are hitting their site.

So you might have a power user and a standard user and an admin. And from their perspective, it didn't make sense, necessarily, to do that on a nit part that we were just talking about a couple minutes ago. Because one time, they need to on a nit as an admin, and another time, they need to on a nit as a super user, and then another time as a regular user.

So that was a problem I hadn't really come across yet. And so I took a few minutes, kind of hashed some things together on my computer, tested them out and said, “Okay. I think this would work.” So I was able to offer him a couple options that way, of “Well, you could do it this way. You could do it that way. Here's the trade-offs of each.” So at that point, it comes down to what you're willing to take on as a team and how your project is structured.

I like to refactor as a developer

Joe: Also, with Protractor, do you know if it also supports the page object that most people familiar with Selenium would know about?

Nate: Yeah. So I think that's the third module of the course. I think it's the last one. Which to me, it's one of those kinds of things that just keeps getting better and better. Obviously, like you mentioned, Selenium's already got the page object. But a lot of people don't necessarily think in that way, or at least that's been my experience.

And so it's been great to go in and setup my page object and say, “Okay, my username input is this. My action button is this.” Or even do a little bit more and say, “Okay, let me get the classes on this page and be able to set that up as a page object.”

So that way, I can go and change one page object when maybe I add some classes or the name changes. Or in the case of Angular, some of the bindings change, I can go change my page object and then suddenly all my tests are working again. And I think in the course, I compare it to if you don't have that, you're going to lose a lot of confidence in your tests, at least in my experience.

Because I like to refactor as a developer. I work on a team of people that like to refactor. And sometimes the refactorings are simple, but sometimes they're things like, “I think a better name for this element is my element.” And then that breaks 100 tests because they were all dependent on it being called “that element” instead of “my element.”

So if we have a page object, we can go to that one place, change it from finding that element to finding my element, and now all of my 100 tests work again. But if I have to go in to each of those 100 tests individually and make the change, realistically, human nature, at some point, we're going to stop doing that and our tests are going to be in this broken state. And we're going to say, “Why are we even bothering running the test?”

So when I found out that Protractor supported page objects, it was a huge win. It eliminates some of that human psychology as where a lot of things fall apart. And it just made it a little bit easier to have confidence in our tests.

Joe: Besides your course – which I think everyone should check out on Pluralsight. You can get a free 30 day trial period and it's awesome – are there any books or resources you would recommend to someone to get them up to speed with Protractor or even JavaScript? Because I think you would really need to know JavaScript in order to use Protractor.

Nate: You know, I've been listening to your podcast, and honestly, I even told a co-worker that was the one question that I was stressing out about. Protractor was one of those things I just kind of picked up and started playing with, and I was like, “Oh, I see how this works.”

Really, what had a bigger impact on me, which led me down this path eventually, was Uncle Bob's Clean Code book and then Kent Becks book on TDD. Because both of those really got me going in terms of having automated tests and making sure that my code was accurate and maintainable. So both of those led me to this point. There wasn't anything necessarily with Protractor or JavaScript, a book or a resource.

I read a lot of hacker news, The Y-combinator, The Aggregator. So I don't know if you guys are familiar with that. It's news.ycombinator.com. And they talk a lot about all sorts of technology issues, whether it's JavaScript or Ruby, or dot net, or whatever the new language is that's going to come out this week.

And I read a lot of Reddit, JavaScript SubReddits and things like that will provide blogs. So when it comes to individual, specific things about programming languages, I rely a lot more on blogs. When it comes to the software engineering principals, that's when I go to books. I'm afraid that by the time I buy a book on Angular, that it's already obsolete. But by the time I buy a book like Clean Code, that's going to last for quite a long time in terms of what does it mean to write clean code and things like that.

Joe: I definitely agree. I think those are great resources for any developer or any tester. If they learn how to write clean code, it would be a lot better with any language or any framework that we use for testing.

Nate: Yeah. Once you start thinking about what is a bug in my software mean, for some people, it means lost time, which for their clients means lost money. But I started my career at Caterpillar, the big yellow tractor company, and I was writing a service tool that talked to all of their engines and all of their equipment. So it's very likely that we could have screwed up and caused someone personal harm, or worse, with a bug in our software.

So once you start putting those pieces together, to me anyway, the clean code just becomes much more important because you realize the gravity of what we're doing as software. It's not all Angry Birds. If that crashes, nobody's really that hurt. But if Facebook screws up and they put pictures up of you that they weren't supposed to, well now suddenly that's a much bigger issue.

If my Capital One account gets hacked or my credit card gets hacked, if the website gets hacked, now it's a much bigger issue because now I'm losing money all the way up to, like I said, personal injury on medical equipment or something else. So that's what started forming in my mind 10 years ago. I enjoy writing software, but it's a much more serious task than I initially thought.

To me, TDD, the tests, are actually secondary

Joe: Absolutely. Can you tell us a little bit more about your other course, TDD? I know you mentioned it in the beginning, so just give a shout out what it's about and how it can help us.

Nate: Yeah. So the first course is TDD as a Design Tool. I talk a lot about TDD professionalism and coding clean code, maintainable code, when I speak at conferences.

And I was having a hallway conversation with another speaker and he was talking about, “You know, TDD is okay, but I bet I can write two or three test cases that could cover 80% of my situation.” And I said, “Oh, yeah, I'm sure you could.” And he was a little taken back because he knows how much I like TDD. And so I was able to say, “To me, TDD, the tests, are actually secondary.”

What I get out of TDD is a cleaner, more maintainable, better software when I'm done.” So the feature is cleaner, it's more easily refactor-able. It's just easier to read.” And that's what, to me, comes out of TDD by breaking it up. So I look a little bit about what is TDD, what does it mean?

But instead of focusing so much on a lot of the TDD courses, where they look at, like “Hey, here's how to TDD a calculator,” I went and took the approach of, “I've never had to write a calculator in my professional career, so those aren't always really helpful.”

So I took an application that actually gets used in the Protractor course and we wrote some back end tests, and then we wrote some front-end tests. And then when we looked at what our code would have looked like had we not done TDD, had we not done that test first. And the application is almost like a Yelp clone, so you can put in some events and you can give it some ratings, and you can leave it some feedback on different things.

And so it goes through, “Here's how you would TDD saving to the database or running your calculation to figure out how many stars this event should have. And here's the TDD on how to TDD a UI.” It's really geared towards trying to make that shift in thinking about what really is TDD, what is the purpose? It's not what a lot of people think, which is, “Let me get 100% code coverage and let me write a bunch of tests.” But those are both side effects of the purpose of TDD. And that's what the course tries to explore.

Joe: Awesome. I'll definitely check it out. It's in line with what I've been trying to tell people about behavior driven development. It's kind of like what you said. It's not really about the test, it's about the communication. And so with the TDD, it makes sense having a really clean API. The side effects are maybe you have tests, but it's a more readable good, I guess.

Nate: Yeah. And it's funny, I've gotten a reputation at work now because I talk about TDD anytime somebody gives me an opportunity to talk about it. So they have this idea now that I'm just in love with tests. So now that's great because they know, “Hey, if we have a question about testing, we can come talk to Nate.” I don't really love testing for the sake of testing, I love what tests get me, which is clean code. And I can come home tonight and be sure that the code I wrote today is working like I told it to work because I wrote tests that verify that.

Joe: That's a great point. I think people get so caught up in the test and they have a check mark, a definition of done, rather than what it's trying to actually achieve, is cleaner code, better requirements, collaboration.

Nate: Right, and I think it naturally flows in with the Protractor, because that's just one more level. So you can do your unit tests. You can have some automated API testing. I've heard some of your other guests have good libraries, packages, and approaches to doing some of those automated API testing. And now with Protractor, you can do the next level which is the next layer up.

You can actually have some automated UI testing. And again, you're getting that confidence that, “I'm not going to base my releasing my software on the fact that my Protractor test passed, but I am going to go into my testing time, my manual testing time, with a lot more confidence that, ‘Okay, this program probably works. Like, it might be 80%, 90% there. I've got to find those cases where it doesn't work and highlight those because Protractor isn't going to find those for me.'” It's not thinking, it's just doing what it's been.

Joe: So at this point for some reason, Nate's audio for Skype dropped. So this was cut off. But I'll just finish his sentence, if you don't know what he was going to say.

He was just saying, “The script doesn't think, it just does what you program it to do.” And that's an excellent point, just because you have tests, doesn't mean it's going to catch everything. It can only catch what you tell it to look for.

So Nate, before we go, is there one piece of actionable advice you can give someone trying to improve their Protractor testing efforts? And let us know the best way to find or contact you.

“So the one piece of advice that I give on any test, any time somebody asks me about testing, is just start today”

Nate: So the one piece of advice that I give on any test, any time somebody asks me about testing, is just start today.

A lot of times, we get hung up on, “Oh, I'm on this Legacy code system and there's so much code that isn't tested.” I like to look at projects on a timeline. So let's say we're two years into a project and we've written zero tests for the first two years. Well, right now that's 100% of our code base. A hundred percent of our code base has no test. Assuming that our code base is not going to end in the next week or so, if we start writing tests, eventually we'll get to the point where 25% of our code base has tests or 50%. And then eventually, it's “We have now more code covered by tests than what we don't have covered by tests.” And I think that's true with Protractor, too.

You can be 6, 8, 9 months into a project, a couple years into an Angular project, and not have any Protractor tests. But you can start with one, and see the benefits that gets you. And I found it actually addicting. To the point where if I'm writing tests at the end of the day, I've actually found myself staying later because I'll write the test and I'm like “Oh, yeah, that one works!” And then I'll write the next test and like, “Oh, yeah, that one works!” And I just get in this little developers high.

It's never too late to start, just start writing tests.

So that's the actionable advice. It's never too late to start, just start writing tests. Like the first time you wrote database access, I'm sure it sucked. The first couple tests are probably going to suck, but don't let that discourage you. Because you're just going to keep learning and getting better.