 If anybody wants to download the presentation in advance, it has some hints on things that you can be installing while we're here during the talk. There's a bit.ly URL. This is actually the last page of the presentation that I figured I'll put it up first. It started. We still have a couple more minutes. Can I get a show of hands here? Who programs in JavaScript currently? Okay. So then I think I've got the right presentation because originally I was going to jump ahead and do a lot of in-depth stuff and instead I'm going to talk a little bit more higher level. So that's good. Who here has been employing agile practices? Okay. Good. How many of you have been employing extreme programming as one of your agile practices? Okay. Good. Well, this is going to be a talk about extreme programming as well. I've been here a few days and I was able to see what the other sessions were about and that helped me modify my talk a little bit accordingly. I felt like extreme programming has been mentioned a little bit into the side, but not so much. And this is one of the hands-on agile engineering, if you will, presentations. And as a consequence, I felt it was ripe to discuss extreme programming. Excuse me. So before I get started, I'm going to grab a bottle of water. Okay. It's 10.30. So technically I can begin. So welcome. My name is Daniel Zen. I run Zen Digital in New York City. It's a small consulting firm. We focus on mobile and web application development. I would say primarily using AngularJS these days. I also run the AngularJS Meetup in New York City. So we're going to talk today about agile practices with JavaScript. I'm going to talk a lot about extreme programming, as I mentioned. I'm going to cover AngularJS at a high level. We're going to do some jasmine testing. We're going to get karma up and running. And I'm going to briefly discuss Jenkins and continuous integration with Jenkins towards the end. So my background. I have a background in extreme programming. I used to work for Pivotal back when they got started. Many of you probably are familiar with it. I was also at Google for about four and a half, five years. I only started using AngularJS about two years ago. I started the AngularJS NYC Meetup about 19 months ago. I reformed Zen Digital as a consulting group. Just about a year and a half ago now. Zen Digital was originally a company I had back in the 90s during the first Internet boom. JavaScript was something I was interested in back then. I was a Java developer. That was my background. I was also interested in JavaScript. A lot of people who were in Java at the time were looking at me like JavaScript. Why would you be interested in that? That's just a scripting language. That's not a real programming language. But I think history has shown that I had some good insight. JavaScript now is probably available in most hardware. Every browser, it's embedded in all of our smartphones. It's ridiculously prevalent. So focusing on JavaScript these days is not just something you should consider. At some point it becomes a necessity. My ability to see the screen from here is really small, so I might turn a little bit. Back when I was first doing JavaScript, I was into extreme programming. I had to do some form of testing. What was available at the time was JSUnit, which is no longer in fashion. Also, I really should find a way to zoom in here. Hold on one second. This always happens when I start a presentation. Size of the screen as I plug into a monitor always makes a difference. Okay, I might do this a lot. I need glasses. I'm getting older. Okay, so what does agile mean today? It's a buzzword. Everybody seems to need to be agile compliant. It means different things to different people. Not everybody doing agile is employing every principle of agile development. I have no idea what happened to it. Thank you. So, as I was saying, it's become a buzzword. I'm seeing everybody here at this conference talk about agile, and it's lost its meaning in a manner of speaking, and it frustrates me because it should mean something specific, but instead it means a dozen different things. What it definitely means is that people are being iterative versus doing waterfall. They're being adaptive versus being predictive, and they're focusing on their code, hopefully, more than their documentation. If you caught Martin Fowler's talk on Wednesday, he spoke about how everybody had a different level of agile fluency, and he had a star system, and he said that most people are at one star, and it's difficult to get to that second star, and I'd like to think that this talk will focus on how to get to that second star. So, here are some of the agile practices that are popular these days. We've got agile modeling, backlogs and products and sprints, behavior-driven development, cross-functional teams, continuous integration, domain-driven design, test-driven development. We've got scrums and can bands and task boards. Once again, focusing on incremental development is really important. Pair programming is something that's very specific to extreme programming, and I'll talk a little bit about that. Planning poker, where you try and figure out exactly how long something's going to take by giving it a certain number of points. Refactoring is something that's also very important in XB, and we're going to talk about that. Having planning, daily review meetings, time-boxing things, so that people don't start talking about something, and before you know it, you've gone off onto a different tangent, or you're not focused on the task at hand. Use cases, user stories, story-driven modeling, and velocity tracking, and that's something that's also very important in XP, so we're going to talk about that a bit. And of course, if you want to see the original Agile manifesto, I have a link here for people that really want to know the origins of Agile. Okay, so probably the most popular Agile practice today is scrum. You've got your planning meetings, your daily scrum meetings, product backlog, sprint backlogs. It's iterative and incremental. It accepts that customers can change their minds. And so people that are doing scrum say, hey, we're Agile. And here we see the scrum process. It's a visual look. I got this from Wikimedia. You can see the incremental process at work. In this case, we have a 30-day sprint defined. And every day, of course, you have your meeting. Usually in XP, that's the stand-up meeting. So we see we've got our product backlog, we bring it into the sprint backlog, and eventually we have a working increment of the software. Now, as engineers, does this tell us how we're supposed to program? Does it say anything about the programming methodology at all? Not really. So it's great from a... That's why I was saying before it's... I call this Agile management. So what does it mean as an engineer? Does it change the way I code? Now here I talk about Agile business. We've got lean development. Lean talks about eliminating waste, amplifying learning. No unnecessary functionality is part of eliminating waste, which also means no unnecessary code. So that's sort of a hint towards the engineering practice. It mentions that insufficient testing can lead to avoidable process repetition. So that also talks a little bit about testing and how to code. But nothing here specifically is about engineering. Once again, people who are doing lean, they say, we're agile. You want to deliver as fast as possible, which means usually continuous integration. So that's also something that's kind of hinting at, you know, we should... an engineering practice. Also in the lean category these days, Eric Rice's book where he talks about the minimum viable product. Some misinterpret this to mean a product that will generate income to sustain itself, but actually the product is supposed to allow the team to collect the maximum amount of validated learning about customers with the least effort. So essentially to test a business hypothesis. So you can put some code out there and see how people respond to it and you can have that data and say, you know what, we have a business model or we don't have a business model here. Split testing and actionable metrics are not necessarily talking about an engineering practice, but they talk about collecting data for analysis. And that's important, definitely, but it's not specifically engineering. And pivoting means, okay, wait a second, we've looked at this data and our model is not working, what are we going to do? So we're going to change direction, we're going to pivot. So he talks about continuous deployment, whereby all code that is written for an application is immediately deployed into production. So once again, we're seeing continuous integration or deployment is something that's kind of hinting at the engineering practice. And of course, people who are doing this say, we're agile. So now I come to extreme programming and this is where my background is essentially. I started in extreme programming, I guess it was 2004. So XP talks about planning like Scrum does. It's got some of the same things, it's got user stories, it's got releases, it's got iterations. So it sounds like Scrum from one perspective. But it also talks about how to, when it comes to managing people, it gets very opinionated and this turns some people off to XP. So XP fell out of favor, it was difficult to fully implement or implement the way that, you know, in, I don't know, the perfect way. It was really hard to get there. So what does it say about managing people? In a room all, put the whole team in an open space. So it actually says, hey, get them up out of their desks and put them in a room all together. That's, a lot of people are like, what? Do you actually want me to change the way everybody's sitting? That's crazy talk, but it's exactly what we did when we were doing XP teams. Sustainable pace. So that means they're not supposed to work overtime, they're not supposed to work late. That's crazy. I want to get the most value out of my engineers. So I need them to stay till all hours. I want them working as hard as humanly possible. Why would I let them go at a reasonable time? I'm a manager. I need to push them, push them, push them. So that's another thing that seems a little different from XP than a lot of other processes. But since they're all coming in and leaving at the same time and potentially eating lunch together, you're actually maximizing the productivity while they're there. So this is another part of the XP practice. Having stand-up meetings at the beginning of the day, that's familiar to most from other practices, agile practices. But the important thing is that everybody show up at the same time and those meetings happen as the very first thing in the morning. And what winds up happening in a team is if somebody starts coming in late in an XP team, you don't say, hey, you're late, that's bad. You actually can put it to the whole team and say, hey, you know, he's coming in late. Should we all come in late and stay later? In other words, reasonable hours are flexible reasonable hours, but the point is the whole team has to be working as a whole. So coming in late is not a problem as long as everybody agrees to come in late and work late. So it's very flexible and it gives emphasis to the team on how they want to operate. So measuring project velocity, that's something that's again familiar. It emphasizes actually looking at the numbers and it gives you the predictability to see how long is it going to take to actually get your code done. Once you have a velocity that's been calculated, that number can very accurately tell you how long is this going to take to implement if you've done your planning game right. And it also says to fix the process when it's broken. And a lot of people have used this as an excuse to turn XP into something completely different. Saying, well, I can't really do XP the way it was defined and it says to fix the process when it's broken. So I decided to change it this way and it becomes something completely different. And there are some people that argue that, well, if you, you know, the different parts of XP, they kind of interlock with each other. And if you take away some of the essential parts, then XP, you know, kind of falls down as a methodology. So that's something to consider when you're doing XP. It also says, don't leave people on the same task for too long. That's also part of moving people around. Now, typically in a project, somebody becomes a specialist on a particular piece of code and they're the go-to person for that particular piece of code. XP says that's really not good. In fact, the classic example is getting hit by a bus. What happens if that guy that's the specialist on that one piece of code gets hit by a bus? You know, and then what happens? It's the only one that knows that piece of code. What are we supposed to do? So we talk about pair programming. That's a big part of XP. And the reason for pair programming is twofold. One, people usually require, you know, organizations require a code review. But is a code review necessary if two people were looking at it when they put it together in the first place? So it kind of gets rid of the code review process because you have two people that are, you know, that are saying yes, this piece of code is valid and good. Also, it changes the specialty thing, you know, so you've got this knowledge exchange. So by pairing up with a different person each day, you can show somebody else a piece of the code that you know well and somebody else can teach you something that they know well. People who are lower level can rise up. People who are higher level can teach. And the argument is, you know, the argument here is that, well, wait, I'm not getting the full value from these engineers because now I've got two people on one task. And as a consequence, you know, I'm getting only half of the productivity I normally would. Well, I can attest that this is completely false. What winds up happening, first of all, is people focus a lot more and they get into flow. And flow is a really important state to be in. You know, it's when you're just moving along and things are just happening. I'm sure everybody has experienced this, whether it be when you're coding or when you're like, you know, skiing or doing some other activity that you're really good at that you can just focus on the task at hand. What winds up happening a lot in the workspace is, you can get, there's so many distractions. Email, for instance, is one of the distractions that happens constantly. But when you're two people looking at the same computer, you really can't look at your email. In fact, you're prevented from doing it because the moment you do it, the guy next to you is like, what are you doing? You can't look at your email. Like, what am I supposed to do now? You want me to be looking at my email, too? So it actually, you know, it gets two people kind of looking at each other and keeping them focused on the task at hand. And that's a really important aspect of pair programming that shouldn't be overlooked. So it also talks about design methodologies. And in particular, it advocates designing very simple systems to begin with. Very often when you get a project, you have a tendency, you know, we're engineers. So we have a tendency to engineer the solution. Occasionally, we see people who over-engineer the solution. But XP emphasized just writing the code, the simplest piece of code that passes the test, that gets the task done. And some people will say, well, what's the point of that? You know, I'm going to have to change it eventually, at some point down the line. Yes, that's true, but you can't predict when you're going to need to change it. And you don't know how you're going to need to change it. And you don't know, you might even rewrite that code before you get to the point where you need to change it for optimization or something else. So as a consequence, XP says the design should actually naturally come out of the code that's being written. And a lot of people have trouble with this as well. They want to engineer the system from the top down, instead of from the bottom up. And that's another reason why I think XP has difficulty getting hold here. But we're going to emphasize that with it. But test-driven design and behavior-driven design development is something that actually emphasizes this as well. So once again, don't add functionality until it's necessary and don't over-optimize or pre-optimize. Also, it talks about having a system metaphor, so that if you're doing supply chain management, you might want to treat it like it's a supermarket, for instance, as an example that was given. So by having a metaphor that everybody on the team can use and deal with well, even if you're not a domain expert on the code that you're writing, it allows everybody to focus on the task at hand without being mired in the difficulty of learning a new domain. Because what winds up happening once again is part of that fluency discussion that happened the other day by Martin Fowler. He was talking about how to get to that three-star or the four-star agile fluency. That's when you actually, you're not just the programmer on the system, but that you become fluent with the domain of the system itself and actually start to push back about how processes should be done in the company. And so this is a push in that direction as well by making things, giving it a metaphor that's easier for programmers to develop with. And finally, spike solutions. So if there's a problem that you're not sure exactly how to solve, the concept of a spike is usually used, where instead of putting it into the rest of the code, what you do is you focus just on the problem itself in a separate piece of code, and you say, I have nothing but this problem, how do I solve it? And you write code that essentially you might wind up throwing away. Probably you're going to just throw it away. But the point is that you discover the solution that wasn't known to you before. And that becomes a very useful tool in the tool belt of the Extreme Programmer. So when coding, the customer is supposed to always be available. And this sort of flips the script that most companies are used to. Most companies think, well, I'm management or I'm the customer and I'm hiring you and therefore you're available to me when I call you, you should be available to me, you should do what I say. But actually Extreme Programming puts the power in the hands of the developer. And the customer is beholden to the engineers, not the other way around. So if the engineers are looking at a user story and they say, you know, what does this actually mean? I have a question. The customer is supposed to be available to answer that question immediately. So if you can't have the actual person that's hired you or that's specifying the system, then they have to have some sort of surrogate that's available that knows the system inside and out and they can answer questions for you. And that's something that actually will prevent bottlenecks because what winds up happening is, you know, engineers have some sort of story that's been written and they read it and they both, you know, they're in a pair, they look at each other and they go, I don't know what this means. Do you know what this means? And they're like, no, I don't know what this means. And so what do you wind up doing? You write an email and you're waiting for an answer. And in some cases, depending on where people are spaced in the world, that answer might take a really long time to come and that's a huge bottleneck in time. For instance, working, you know, outsourcing things to India from the U.S. usually means that people are working at a different time schedule. And so if you actually wind up asking a question on Monday, you might not get an answer until Tuesday and then you can compose your response to get it on Wednesday. And so, you know, just a back and forth can take three days. So that's sort of untenable in the XP world. And so, you know, XP was one of the, you know, one of the tenants of XP kind of was against outsourcing just because you're supposed to have everybody in the same room. Now, don't get me wrong, it's possible to do remote pairing and it's possible to, you know, we have the internet these days. So as long as both people can see the same screen, it's possible, but that still doesn't change the fact that they both have to be available at the same time. So that means somebody has to flip their time zone in order to be able to work on a team remotely if they're in a different time zone. I'm currently working on a project where one of my designers, he's up all night. And as a consequence, during the day when the developers are all saying, you know, we need something changed, we have trouble reaching him. And then of course the next morning we walk in and there's all this stuff that's been done. And it's, and I'm realizing that this isn't working for us and this is actually something that I'm going to have to change because once again, this is the process that's been, you know, I've been told that people should be available at the same time. So the team should be there at the same time and the customer should be there at the same time. It's very important to have standards when dealing with an extreme programming project. And by standards I mean coding standards, variable naming standards, formatting standards. The code should look like it was written by a single person potentially or at least a group mind. You know, you shouldn't be going in and seeing that formatting is different depending on which programmer was, wrote that particular piece of code. The indentation shouldn't be changed every time you do, okay, let's reformat this code and everything moves over to characters and when you go check it in to get, you've got a thousand line change when really you only changed a few lines. So that's really, by conforming the same standards you won't have problems with the reformat changes. It'll make the code look it was written by like a single person and this will lead to a sense of collective code ownership. And that's one of the other things in XP that confuses people. It says that any developer on the team is allowed to change any line of code on the project. They can be confident that they haven't broken the subsystem because there will be unit tests. And so unit testing is something that's probably been discussed in a lot of other agile practices but in extreme programming, the engineering agile practice it's emphasized to the nth degree. You can't not have unit testing with XP. It's just not allowed. And with TDD they'll be written first allowing you to determine what needs to be done and giving you immediate feedback. Consistently writing tests will give you the confidence that your code works even if you decide to make radical changes. Now the word scaffolding kind of means something different in computers but before scaffolding had its current use I used to think of the tests as scaffolding to my skyscraper code and I used to think that the tests were sitting there making sure that if I made some radical change to my code I could rely on this scaffolding to make sure that I know that the changes I made to the code did not affect it adversely. That was the way I used to think of it. I probably need another metaphor since scaffolding is overloaded these days. So all code must have unit tests. All code must pass the unit tests. When a bug is found, write another test. This will prevent regressions. Regressions is the horror of all of us. If you have a bug that gets introduced, you go and fix it the next thing you know a week or two passes and that same bug has popped up. Why? Because you didn't write a test to prevent it from popping up again. If you write a test every time you see a bug and then you run all your tests, that bug should not be able to happen again. And that's hugely powerful and prevents wasting time. It makes making us more efficient. And acceptance tests which are based on the user stories should be run often. So I'm going to be focusing on these aspects for the rest of this talk. Test-driven development or behavior-driven development which means having unit tests, automated testing of the functionality of your code. TDD has a suite of tests on a piece of code. BDD for a piece of code describes what it should do. So it's really just the nomenclature. The tests look a little different when you're dealing with behavior-driven design but essentially BDD is a superset of TDD, if you will. Small releases, so iterations, frequent releases of live functioning code and continuous integration. Dev teams should always be working on the latest version, uploading your code to a repository every few hours at most. So last night during the panel, I remember Chad responded to a point regarding why Agile isn't more prevalent today. Somebody was saying, if this is the Holy Grail, why isn't everybody using it? And he was saying that today's managers are yesterday's engineers. So some managers come from a cobalt or a mainframe background and don't tend towards Agile. However, those engineers who have been brought up on Agile in one form or another are more likely to adapt and install those practices in their teams today. And if you want to get to two stars, these are the practices that I'd like you to emphasize. So getting started with behavior-driven design with JavaScript development. So I'm looking around. I only see one person with a laptop or two. So this is probably more going to be me showing you how things are done. I tried to make this a hands-on demo so that people could download and do this themselves. I'm on a Mac. You might not be. I tried to give installation instructions for a lot of things. So since everybody has the URL, everybody can move at their own rate and feel free, if you don't want to do this now, that's fine as well. I did pre-write some things, which I haven't uploaded yet, but I will be providing them. I just didn't want to have to be doing them all on site and then have a syntax error and be sitting here trying to fix it while everybody was watching. So Jasmine. So there are other JavaScript testing frameworks besides Jasmine, notably Mocha. But since I'm an AngularJS user and the AngularJS repository itself, the tests were done in Jasmine. I focus on Jasmine. Jasmine is behavior-driven development, testing framework for JavaScript. It does not rely on the browser, the DOM, or any JavaScript framework in particular. That's it suited for websites, no JS projects, or anywhere that JavaScript can run. And here's the GitHub repository. You could go and download it directly from there, but on the next page I'm going to talk about different ways to install Jasmine. Yes? Well, it's the JavaScript aspect of the website that's going to be tested. But you could be testing server-side. You can do end-to-end tests in Jasmine as well. So that could be testing server-side because you're actually testing, you know, you give it an input, you get an output. So treating it like a black box, this is an acceptance test. So that means the server has to be working as well. So yes, you can be testing websites, you know, server-side with Jasmine, but essentially you're not testing just the server-side, you're testing the whole process. Those tests can sometimes be a little slower, but at the same time they give you, you know, that's what gives you your acceptance tests. What used to be known as functional tests. There was a recent version 2.0 that just came out. Most projects are still using 1.31. I'm going to use 1.31 for the examples here, but if you're using Jasmine for the first time, feel free to install Jasmine 2.0. So just so you know, we still have another hour, and since we're getting into the interactive portion of the discussion, feel free if you have some questions to ask them. So here we're going to look at a simple, so anybody who has a browser, you could probably even do this from your cell phone if you wanted. There is a live version of Jasmine up and running at the triedjasmine.com website. So I'm going to run it right here. This is the code that comes in by default, and here's the spec, is the specification for how the test should pass. So many of you might be seeing this for the first time. This is your first time seeing a behavior-driven design specification format. It's designed to read like English, so it says here, describe Panda, and the function is silent. It is happy. Note that is happy is a string. This is just a description of this behavior. So it is happy is the description of the Panda. Now, usually the notation for BDD would say should be happy, but this is the default in the triedjasmine, so I'm showing you what will pop up if you actually go to triedjasmine.com. But typically, behavior-driven design tries to use it should as the language of the behavior, because it might fail, so you're saying it should be happy. Now, following this is the expectations of the behavior. Expect the Panda to be happy. So it reads like English, and that's one of the advantages of BDD versus TDD, is basically they're doing the same thing, but it's been redefined so that it reads a lot better, and that helps when you're writing your tests and looking over old tests to understand what it is that's been written as the test. Now, the source code for the Panda is the bottom here, and when we look at the Panda, we see that, in fact, the Panda is sad. So if we run the test, and I'm going to bring this up now, hold on, it goes a little bit off the screen, but everybody can see everything, that's good. Here, I'm still, you got this here? Hello? Testing? Okay, thank you. So this is the triedjasmine website, and once again, this runs almost anywhere that you have a browser. So we can click here, the button triedjasmine, and oh, I've already changed happy to sad to happy. Now, it's actually important in extreme programming and test-driven development that the test fails at first. You don't want to see a passing test initially. Now, does anybody know why you want to see a test fail? No? That's one reason. Usually if you're writing the test first, that means that the code is yet to be written, so the test would fail, you know, as a matter of course. But there's another reason. What happens if you accidentally write a test that always passes? And I've accidentally done this. I've been doing this a long time. There's some error in the logic of your test. There can be errors in your tests, just the same way there can be errors in your code. So it's really important to see that your test can fail and will fail when the input is incorrect. So now we change this to happy, and now we see our test passes. So who's seeing Jasmine here for the first time? Cool. I feel really proud because I'm exposing all of you to this. So thanks. English. Yes. No, this is designed for engineers. This is part of agile engineering, not agile management. So this is meant for something that the engineers who are paired up are doing before they write a single line of code, they're writing a test. This is true. This is not something, you know, now there are other testing frameworks that allow you to give something to management for them to write in English. Jasmine is not for that purpose, admittedly. Anything else? Okay, so I'll leave it this way. It's fine. So there's a couple of reasons why the test is set up to fail first, as I mentioned. And also you want to make sure you have an accidentally written test that always passes. So seeing the test fail ensures this is in the case. So here's a test-driven development flow chart. Typically the first thing you do is you write a test. And then you see the test fail. You write your code. You run the test. And if necessary, or almost always, you're going to refactor. So you're writing the simplest thing first and then refactoring once you get it right. Yes. Oh, I'm sure you can, maybe you just set the, there's a mode for coffee script, but I think, what? That's a bit of a discussion for another day, but coffee script is sort of a variation. It's more like Ruby, but yet it compiles to JavaScript. I'll leave it at that. I'm going to move on. So you could download the release of Jasmine from GitHub, but of course you should have Node and NPM, the Node package manager installed. So let me get a show of hands, just who's ever used an installed Node and NPM. Okay, that's about 50%, that's good. So if you're going to do JavaScript development, these days Node is just a necessary tool. Even if you're not writing server-side JavaScript, there are so many utilities that have been written with Node and have packaged up with the Node package manager that you really need to get it installed. So I give you a bunch of links here on different ways to install Node. You can go straight to the Node website, which is one way. There's also talking about installing with Homebrew, which is the way I've installed it, because I'm on a Mac and Homebrew is a package manager for the Mac. There's also the Node version manager, which is very popular. And then talking about how to install Node via different package managers for various versions of Linux. If you're on Windows, you're probably just going to install it straight from the Node website. So once you have Node installed, it's really easy to install a bunch of other JavaScript-related tools. And one of them is Bower. Now, Bower was created by Twitter, and it's basically a front-end JavaScript package manager. So what do I mean by that? Node is for server-side JavaScript. But things like Angular are pieces of code that get put on the front-end side. So what happens when you're starting a new project and you're like, oh, I need some sort of library to do a JavaScript framework. I need some sort of widget so that I have a calendar. I need some sort of... Now, Bower is in the place to say, hey, why don't we just download the small piece of code that we need and install it into our web folder, and suddenly, bam, it's ready to go. Instead of having to go and download the code and then find out where to put it, Bower takes care of this for you. Admittedly, sometimes it'll install a lot of extra files that need to be weeded out, but when you're doing development, you don't care about extras, you care about getting the code up and running at first. You can pair down the files and limit it to what you need later on once you have things up and running and functional. So here I write how to install Bower. And I used Bower to install Angular in the examples I give later. The first thing I would recommend is installing Bower. So it's a package managed for the web. So you can also take a look at Bower.io slash search, and you can see all the various packages that are available through Bower. And it's a really huge list at this point. So it becomes a great utility for doing web development. Jasmine alone, there are 40 different related packages. And so I decided to install the 1.31 so the notation is to say Bower install Jasmine and then the pound or hash sign 1.31. Otherwise, it would automatically install the 2.0 version. Let's see. So here's where we're going to get a little interactive. How does this work? Not as well as I'd like. Okay. Not as visible as I'd like, but make it a little bigger. Okay. So I created a folder. Let's create a folder in my project directory. This is difficult. I'm looking over there. So I already have these things installed. So it's going to be fairly easy for me to just say Bower install Jasmine and I'm going to do pound 1.3.1. So this actually goes out to the web. I already have a cache. So because I've downloaded it once before, it actually keeps it in a cache because I might be working on multiple projects. So the first time I downloaded Bower will keep it locally cached for me. So it quickly, quickly installs. The most recent versions of Bower now place everything in the Bower components folder and you can see there Jasmine's been installed just like that. So instead of me having to go to the Jasmine website and download it and unzip it, I'm going to have to type this command in and I have it. Let's take a look at the folder structure. Let me see. So here's Bower components. There's Jasmine. So you can see it installed a lot of files related to Jasmine. Not all of which I'm going to need. But I'm going to focus on the lib directory. There's the Jasmine core. And there's examples. And there's this thing called a spec runner, a specification runner. It allows me to run the tests in a browser. And there's some sample code here. I'm going to open this up now in Sublime. I can just drag Jasmine core to Sublime. Bam. So here's my spec. So once again, this is written in Jasmine. It's behavior-driven development. It says describe a player that has a variable player and song and before each test. One thing that's available in Jasmine is to run a bit of code before each and every test so that you can do setup. So before each, I know it's really hard to see there. It says player equals new player. And it says song equals new song. And then it describes it should be able to play a song. So the player, you should be able to call play on the player and specify a song. And that expect the player to now have a variable current playing song to equal the song that you told it to play. Can everybody read this? And I don't mean like, can you see it? I mean, can you read it the way I just said it in English? Can you see that I tell the player object? People here all have object-oriented programming backgrounds. Can I get a show of hands on object-oriented programming? Okay, cool. Just want to make sure. So everybody sees that the player object has a play method and that I'm passing a song in and then expect the player is currently playing song to equal song. And then I've created, there's a custom matcher that's available and this is something that you can do with Jasmine. So there, matchers can be something like to equal is a built-in matcher. Say that some, you can expect something to equal something else but to be playing, that's not something that Jasmine knows by default. That's something that's been defined. So in the example here, there's something called a spec helper. And the spec helper has that before each, it's an extra before each and it says, add this matcher to be playing a function that when passed an expected song, sets the player to equal the actual player and then return this Boolean expression. Player dot currently playing song is equal to expected song and player is playing. I know you're probably having trouble seeing the equals and the ampersands of end, but trust me, that's what it says. I'm doing the Boolean logic here. I'm sorry about it not being that easy to see on the screen. Does everybody understand the logic behind this? Does anybody have any questions about this custom matcher in Jasmine? Okay, yes? So this is the ability for us to write a custom test that we can use in our testing framework. So matchers basically check that two things match each other or are equal to each other in some way, shape, or form. The classic one, as I mentioned in Jasmine, is to equal. Here we're defining one called to be playing. So the reason why it starts with the word to is because it's part of an expectation. So in English, because of its behavior-driven design, it says expect, so if you're using to equal, you're saying expect something to equal something else. Here we're creating a matcher for a player object. So here we're saying expect player to be playing the expected song. So it's meant to be, not necessarily as easy as Cucumber, but it's meant to be able to be read in English by a programmer. This represents the test that you're running in. So the player in this case would be the actual player that you're dealing with. So there's an actual player and then there's, and so you're checking the actual player. So it's this object in JavaScript refers to this object that's actually being run. So there's an actual variable inside of there. Let's take a look back at, yeah, it's a key word in Jasmine. I'll get into that later. Is there any other questions? Yes? How does this what? And you want to add this matcher into the other spec as well? Okay, well, I haven't showed you the spec runner yet, which admittedly is hard to see on the screen, but the spec runner specifies the addition of the spec helper. So when it's actually running, it specifies which files get added. So all the JavaScript files get added here. Now, unfortunately, for anybody who's trying to play along at home, there is a problem with the default installation. This is not because of Bower. Actually, I went in to download it straight from the Jasmine website and it had the exact same problem, which is it's referring to live Jasmine release candidate one. This file was never updated in the repo. If we look at the actual file structure, we'll see that the Jasmine CSS is actually just one folder up from the spec runner, and the Jasmine JS is one folder up from the spec runner. Here's the Jasmine JS, and the Jasmine dash HTML JS is one folder up. So you actually need to change this, and this, you know, I should probably submit a pull request. If you make these changes, then you can run your spec runner. So I'm making these changes first, just so you see. So basically it says load the spec helper and then the player spec. And so that's what's specifying that the spec helper be part of this test. It's in the spec runner, specification runner. Does that answer your question? Yes. I mean, we're going to go into... This is actually a simplified version of Jasmine. We're going to move towards Karma Next, which shows how things would be run. I'm just trying to do this piecemeal. So right now we're just going to run it in, and essentially you'd have a different... In this model you'd have a different spec runner for every single test, or you'd have one super spec runner that would run everything. And also it doesn't really matter if we add this to be playing function in. We're just defining it in here. This is just defining to be playing to be this function. If we never call it, it doesn't matter. So it doesn't matter if we add it in as long as we don't call it. A little bit, yes. If you're running hundreds of tests in your domain, then you might be using this in various different places, and you might have a single scope, or before each is something that can be used to clear the scope and start with a fresh scope. So putting it in a global before each is a little bit much, but since it's a test, usually matchers are added in at that global level, because they could be used everywhere. There's a setup functionality that wouldn't be done at this global level, and that's how come when we look at the actual player spec, we have another before each. Each before each gets run. So this one's a more localized before each, and if you look, it's in the describe. So only within the scope of the player will this before each be run. So that's a different, so it's a sub-scope, if you will. So you're right, the to be playing is in the global scope, and this before each is in a smaller scope. Right. Basically expect will run fine if there's a problem, otherwise it's going to throw an exception. This is actually how you specify that there's a problem. It's going to throw some form of exception. Yeah. Well, when you have a to, if the method here returns true, then it's not going to expect is the one that throws the exception. All you have to do is return true or false, and then expect will take care of it. Any other questions? Okay. Cool. Going back to, okay. So that was very quickly getting Jasmine up and running. I'm losing my presentation because I'm jumping around. There we go. Okay. So we've created the project and we went over. I probably am already a slide ahead. Yeah. So here we are. I show, for those of you that are just, you know, that just for anybody that's going to look at this, at just the slides, they can see examples of the code that we just ran. Let me just actually, so we run in a spec runner. We fixed the errors in the spec runner. Oh, so let's say, yeah, we haven't run it in the spec runner yet. So let's actually run the tests in the spec runner. So let's go back to, so here we are running in the spec runner, and it says zero failures, everything passed. Well, that's not that useful. I mean, it is in the long run. You know that everything's running. And once again, typically when you're writing your tests, you want to see them fail first, but we're not seeing any detail here. However, there's a little checkbox here that says show the past tests. So just by clicking on it, it actually will display the tests that passed. Usually you want to focus only on the tests that failed, and that's what the spec runner does visually. So here we see that the player, when the song has been paused, should indicate that the song is currently paused, and it should be possible to resume. And resume should throw an exception if a song is already playing. The player should be able to play a song, and the player tells the current song if the user has made it a favorite. And so essentially these tests, because of behavior-driven design, driven development, you can actually read them very easily. And of course the tests are available for you to look over and to study at your leisure. So AngularJS. Yes? No problem? Yes, yes. You're jumping ahead. I'm just trying to piecemeal it out, but we're going in that direction. Well, that would be something that would be the responsibility of your repository. If you've checked everything into Git and you have a build that has errors, you should be able to roll back to the previous commit. Is that the question? Yes, but the before each is resetting the environment each time. Yes, that's why you have you write the before each once, and that before each resets the environment and sets up all your variables. And that's run each and every time. You can also have an after each that can clear stuff away to get rid of resources if necessary. So that way each and every test is being run in a clean and pristine scoped environment. Sometimes there can be test dependencies that are unforeseen, and that's actually bad. You want to really clean up and start every test fresh and clean. So moving on to AngularJS. AngularJS is a framework that I championed a little bit. I run the AngularJS Meetup in New York. It's open source framework. It's maintained by Google. It was created by a friend of mine named Mishko Heveri. And that's actually the reason why I got involved in it. I was looking for a web framework and I did a search with Google. And it said I was looking for Backbone, actually. So people here probably from, you know, if you do JavaScript development, you're familiar with Backbone. And it said people I knew were talking about Backbone. So I went and looked at who was talking about it and it was Mishko. And Mishko was comparing Angular to Backbone. And that's when I found out about Angular and I started to delve in deeper. And before you knew it, I'd gone down the rabbit hole and now it's my favorite web development and web development framework. So it's really well known for running single page applications, which seemed to be the modern applications. A lot of people were developing in Ruby over the last half decade or so. And Ruby didn't really create a lot of single page applications by default. It made it really easy to create web apps that went from page to page with full page reloads. But Angular makes it really easy to make modern looking web apps that actually dynamically change pieces of content on the screen as you move along. It has a model view controller capability. It can make front end testing easy or easier at the very least. And that's something that's really important. A lot of people kind of dismiss testing front ends. They think that it's hard to test a front end or it's even not possible or it's declarative because, oh well that's the way it looks and I'm testing to see that it looks and I say it's supposed to look. And they give up on the testing for the front ends. And I'm here to tell you that you can test your front ends and that AngularJS makes it easier to do so. So AngularJS adds custom tag attributes to HTML. So when you look at Angular HTML it doesn't quite look like HTML5. In fact there have been some talk about making some of the techniques and features inside Angular part of the HTML6 spec. So conceptually some of the functionality you're seeing here might actually be part of the way the web works in the future. It's got two way data binding. It's actually really well known for this. It's a very powerful feature. It allows you to bind an input or an output to a particular of a particular element to a standard JavaScript model. Any variable in JavaScript the value can be in an input element or just output on the screen. So that if it changes because the user input changes it or if it changes because some calculation changes it it will automatically update on the screen. And the power of this is pretty amazing. It basically means you can define your user front end and the values that are going to be in there and you don't actually have to do all this update logic that's typical with something like jQuery where you're actually saying every time this changes go and make these modifications to the DOM. Instead it's very declarative. You're sort of saying this area of the DOM this value in this element is whatever this variable is and just is that. And if that variable changes then the screen will update and it will just change. Yes? Why don't we talk about that after if you don't mind? Okay, thank you. So the JS model as I said you can manually set the variable or it could be retrieved from the server as a JSON resource. JavaScript object notation. So the declarative nature of AngularJS can throw developers at first because it looks different than one expects. People are usually very quick to see how powerful it is but sometimes get frustrating because it doesn't do things the way they expect to do things or they get confused by it's different. It takes a little getting used to. So it's very different than an imperative programming paradigm like jQuery. It builds UIs with declarative programming and it decouples DOM manipulation from the application logic. It makes testing easier as I mentioned. It also decouples the client application from the server side. Typically, what you'll do is you'll define a REST API and then once that REST API is defined you could use something like apiary to kind of mock it out and then you could start writing the front end based on some mocked out back end and then another team can be working on the server side and you can be working in parallel very easily. And also then you can reuse these pieces of code. You can create widgets that you create might be used on different projects and the back end API might be used for different front ends for instance a mobile app whether it be iOS or Android might use the exact same back end REST API. Yes? Oh apiary. It's good for mocking out APIs. It's actually a website. I'll just open it up real quick. That's no good. Am I offline? Yes, I'm offline. Turning Wi-Fi off. Turning Wi-Fi back on. Well I'll get to that in a second. Fortunately my talk is downloaded already. Oh there we're back online. Let's try it. So apiary is just a website that I've stumbled upon. Since I deal with Angular a lot I'm creating REST APIs a lot. So apiary can help you mock out an API very easily. So it's a very useful tool. That's the thing about writing apps today. When I started with Xp back in like 2004 all the tools that are available now it's just ridiculous. In fact it's a little overwhelming because just learning the tools can be a task in and of itself. You walk into a project and if it's already up and running you usually have to learn every tool that's on the project but if you start a project today versus two years ago the tools that are available now it's amazing how people start using them like they've been around forever and they all stand on the shoulders of giants. These tools are really incredible. Just the fact that I was able to type a few lines and install Angular using the Bower Package Manager the amount of times I had to install and configure various pieces of code that now there's the Node Package Manager there's all these ways to just quickly install things that weren't available in the past and configuration used to be a nightmare. So this is something I recommend. I can add it to the resources it would be useful I suppose. I'm going to talk a little bit about mocking in a bit in relation to Angular in particular. But yes, you can create mock objects with Jasmine, yes. So I was just about to get to that. We're talking about dependency injection. So that's something that's built into Angular. It's been designed with dependency injection in mind. So that makes it easy to create stubborn mock objects for testing. So if you're actually dealing with the live version of let's say an HTTP server you can mock out an HTTP server so that you can say oh well when you request this URL this is what it's going to get back so that if you don't even necessarily you can run tests without actually having a live server available to you because you can just mock out a fake server for the testing purposes that responds in a similar way that your live server will. It encourages loose coupling which puts the presentation the data and the logic separately. Now of course we're all coders it's possible for us to couple these things together despite the fact that it gives us the tools to decouple them. So it's up to us to try and keep these areas separate so that we're not bleeding over into these different areas. So here's some of the pros of AngularJS. It's got testable front end framework. I used to use JSUnit and Selenium which you can still use Selenium. I recommend that that's something maybe also for other resources. Selenium is a very useful testing framework for end-to-end tests or acceptance tests. Although it's a lot slower than writing tests with Jasmine end-to-end tests. So it can do certain things that Jasmine can't but it takes a lot longer. So if it's possible to write an end-to-end test in Jasmine I would recommend it over writing using Selenium. So nowadays we've got Jasmine and Karma. I used to use JSTestDriver. Karma and JSTestDriver they're both test-runners and we're just about to get to that next. So AngularJS has less code which means less bugs. If there's less lines of code there's less places for bugs to be introduced. So if you can write code in a more concise fashion you can minimize the number of bugs. And I think that was one of the reasons why Ruby was very popular and I think it's one of the reasons why AngularJS is very popular. It also makes it easier to maintain. Directives which are like custom attributes, HTML attributes. Directives allow for re-usability. You can write functionality in a directive and then just put that directive in different places in your HTML code and get the same functionality in multiple places with just one word which is very powerful. It has promises for asynchronous. It's very opinionated framework which means they're like this is the way things should be done and you sort of have to do things the Angular way. Some people look at that and go but that's not the way I want to do it and then Angular is not for you. You really kind of have to learn the Angular way but if you want to use Angular. But once you do, trust me, it can make development a lot easier. Especially for very high end, highly functional apps. It's got a lot of momentum right now and of course it has single page applications which are very popular right now. Yes, you can create little widgets and you can also make just a small portion of a web page an Angular app. You don't have to make it prevalent on a whole page. So you can actually insert Angular into another project with great ease. Also there's been some discussions lately about how to compartmentalize pieces of Angular code for reusability. Some of the standards for how to organize your code in Angular are being changed right now in order to make that easier. So unfortunately some of the examples that are given just the organization of the files is starting to change. And so don't forget all of your programming practices when you look where you put your files. In fact the example that I'm going to use later I actually I put code in different places than the standard example did. So what are some of the cons? Well the portions of the page that you have Angular on it really wants to own the DOM. It's very difficult to mix in the exact same area of a page jQuery type of imperative logic with AngularJS's declarative logic. Now what you can do is define a directive and in that directive you can have all sorts of jQuery code. A lot of times I'll get from a designer he'll be like oh I decided to add not just HTML I gave you but I put in all these cool jQuery things that I don't really know how they work but I found a library and I was able to include it. Unfortunately when you try to take somebody else's jQuery work and then put it into Angular it's not that easy. You typically want to start with Angular widgets or components to begin with. It's possible to wrap jQuery with Angular and I've done it it's actually not that hard if you know what you're doing if somebody's done a lot of work already and already created the app if you will in jQuery it's not that easy to suddenly turn around and you have to basically rewrite it to turn it into an Angular app. There's still not a lot of coders that know Angular that well but it's really it's maturing and it's growing and it's happening very quickly so I'd say now is a really good time to get involved with it. Here are some notable AngularJS directives just so that they'll be familiar to you I pulled this straight off of the Wikipedia so ngapp is defines the area of the screen where your Angular app is it's sort of like the root of the DOM element that contains your Angular app and like I said just a portion of a web page can be an Angular app it doesn't have to take up the whole page so you put ngapp in the root DOM element. AngularJS bind is part of the two-way binding that I discussed earlier so it automatically will change the text of an HTML element to that of a given expression and that can be either an input element or it could be just expressed inside of a div as a static text that updates automatically and that's really powerful. You know I'm going to open up right now the AngularJS home page just so that I can show an example of this and then I'm going to get back to this and see it at work. I also gave a talk at the Angular conference the ngconf and ng is typically the abbreviation for Angular so that's why I was called the ngconf in case you're not familiar with it. So I'm going to go over this example soon I think I should minimize so you guys can see the left and right side of the screen. Green size is my problem. Okay, so basically here's the hello world app that I'm going to use. I type my name and instantly we see the output here and if I change it as I change it it changes instantly. Let's take a look what code was written to create this functionality and once again this is declarative code of a sort. We have our ng app at the root element so tells AngularJS to be active in this portion of the page. In this case we put it on the whole page but we didn't have to. It's in the html DOM element. We have to load the AngularJS JavaScript code so that we can use the framework and then we have a model let me move this over and we can read this out so this links the form and the model so basically it says the value of your name will be put into this input or vice versa it's a two way data binding. If we change the value inside of this input it will change the value of your name the variable your name. So when it's empty it says that's standard html enter a name here and then this is all that has to be there. These squiggly braces are a declarative way of specifying a data binding locally in html so all I have to do is put the variable name there and it'll show up there that's it. There's no code that says when this happens do this this is the declaration that that input is your name and that we're going to say hello and the value of your name. So I don't know people are probably seeing this Angular functionality for the first time I hope you can understand how powerful this is and once again we've got a few new attributes in html as a consequence of this but very very little effort has created a lot of functionality very quickly can everybody see that? Is there any questions on this? Yes, yes in fact that's what I was saying when you want to try and convert functionality that's been created with jQuery very often what happens is people write a custom directive that they wrap around the jQuery model and what's happened now is there's whole libraries of custom directives that people have written all sorts of things and once again using Bower you can just install these libraries as you go along so you can be you know you can say Bower install Angular and then later on say oh Bower install Angular UI for user interface widgets install all these different so as you find out about these different libraries that are available you can use Bower just install them and start using them right away and because they're just directives once they're defined all you have to do is put that directive and here sometimes it's just as easy as adding a simple tag to an element to give it immense functionality things like calendar drop downs for instance you know all you have to do is declare something a calendar element and suddenly you have the ability to have a drop down calendar just by specifying that that's what it is okay back to so ngapp as I mentioned ngbind ngmodel these are things that we've seen already ng class allows class attributes to be dynamically loaded controller is a very very common thing you have the controller is where your model actually is stored and what controls the logic it's where you actually store both the model data and the controller logic when you're when you're actually making changes to the page this was a very simple example I just showed you so there was no controller logic and the model was kind of just injected directly into the page instead of actually having the model in a separate file so typically you'll have controller javascript file and then you'll specify the controller for a particular ngapp you also have functionality like ng show and ng hide which can conditionally show or hide elements on the page based on the value of javascript object whether it's true or false objects on your page can appear or disappear with simple boolean logic ngswitch it's one template from a set of choices so you could say if this happens this is what you're going to see if that happens this is what you're going to see and you can have logic that gets run as a consequence right in the template of the page ngview can allow for navigation so now you have these single page applications that actually have built in front end navigation without even going to the server necessarily you might have all the data cached locally to navigate among different pages and you can define an ngview to be a subset of a page so once again this allows for single page applications you don't need to refresh the whole page you can just refresh the ngview DOM element as you navigate so that gives you your single page application functionality yes and the back button works and url copying and pasting will work as well using html5 mode you can actually create a url that will remember exactly where in the app you were and load you up and bring you right back to the exact same position even though you're in a single page app unlike something like flash for instance question I'm sorry are you using angular js is that oh I see well have you set html5 mode that's usually okay I mean I'd have to take a look afterwards I obviously can't debug your code from here but gotcha well I've definitely created routing logic so you use routes to create single page applications and able to route around inside of your app we can talk about it afterwards and ng of statements so that can give you statement directives which allow to show the following element if certain conditions are true different than ng show and hide you actually won't render the element at all so this is the to do example and based on the amount of time I have I'm thinking I'll just tell you where it is on the page so once again on the exact same page that I was just showing you if we scroll down a little bit there's the to do example so it's a slightly more complex example it's got the controller and here's the example of it right over here so the controller is actually defined in here so here's where the logic of the app and the model of the app are so we start with initializing with two different objects inside an array the text says learn angular and done is true and then we can see over here learn angular has already been ticked off and the second object has text build an angular app and done is false and here we can see and that's our initial now we also have the functionality to add a to do item so finish talk and I think I can just hit enter and bam dynamically gets added to my to do list what did to do do what is add to do so basically it looks inside the scope we have a scope object inside angular it looks inside the scope and says for the to do object which is this one here push a new element onto the array with text of whatever is inside the to do text which is here and done is false initializes done to false and then I can actually click finish and make finish talk true or false by clicking here so let's take a look at the html again so how does it put the line through here it defines a class done dash whether or not to do is done or not so done dash true or done dash false is the class that's going to be added onto the object based on whether or not the item is done or not let's take a look at the CSS so basically if done dash true is set the text decoration gets aligned through and the color changes to gray so once again this is very and so now how do we use ng-repeat to repeat through all of the to do in the to do array so as we go through the variable to do will mean that separate scope is created to do is set for the zeroth element the first element the second element etc we show it visually we have an input check box and of course we attach the class to the span and then we have an ng submit that calls the add to do function that we saw on the controller and we specify for this div here that the controller is the to do controller which is defined in to do js the to do controller and this is how angular works any questions on that an example here doesn't do in fact I'm going to run out of time unfortunately but I was getting to I was getting to karma next which talks about setting up karma and then and basically you can I'll show you I guess I'm going to jump straight to what a front end test will look like so let's just jump straight there since I'm at the end of my time so I've got karma up and running here and basically karma launches a browser so that it's sort of the javascript environment that it runs inside of now it's possible to do stuff like this headless but it just uses this as the host environment and then let me bring up a hello world specification so this is a front end test for a hello world app now it's a little confusing at first but a lot of this is the exact same thing you're going to be doing over and over to set up an AngularJS test so it's kind of the first time you see it it looks crazy but before long you're doing it over and over again and you're like oh that's just normal so it really takes a little getting used to and it's very difficult the first time because you're like well I don't know how to write a test in Angular so unless somebody shows you it's not going to be easy it just starts to flow so here we are we're describing hello world and we have an element and before each now we have to set up the environment to be able to use AngularJS testing so we're using dependency injection here to inject the Angular compiler which is what's actually happening on the page live when you're running it the Angular root scope and the Angular controller which in this case actually I'm not using a controller but I put it there just so that you know that typically that's something you're going to inject so now we set the scope of our test to just be the root scope and we're going to create a variable called name inside of the scope with the value world and then we're going to create an Angular element hello name and we're using this is the exact same with the squiggly braces that you'd actually be putting in the actual front end so now if you created a custom directive you could be testing your custom directive here in this case I'm just testing built-in functionality that exists inside of Angular but if you could be testing your directives this way so this is how you'd be testing a front end and so now we have the definition of here it should equal hello world and I actually have it set incorrectly hello name because I wanted to give the example and have the test fail at first so so every time I make a change to this file so unfortunately you can't see that my test has failed just because the colors are a little bit washed out so if I change this to and it says here why it's failed it says expected hello world to be hello name and that's my problem so if I go in here the thing about Karma it's an automated test runner and you can get the time to show setting it up but Karma is what you would be using as you're running your project and something that would be running on your continuous integration server so if I just change this I'm going to make this a little bit more visible as I do this and I'm going to just so that you can see everything happening at once I'm going to change this name to world and I'm going to hit save and now what happened it didn't flow to the bottom but I'll do it one more time I think now I'm at the bottom it actually automatically runs the test it's actually watching the file and every time I make the change it runs the test again so this way I can see my I don't have to actually say now run my tests the tests are automatically being run because I have an auto set in the Karma test set up configuration and so if you're going to do this for a continuous integration server you wouldn't have this this is for development mode you can just have a little light in the corner that turns on green or red a little area of your screen that specifies whether or not your tests are green or test are red and you can just keep editing your code and the moment you're done with a particular piece of test or code you'd see instantly whether or not your tests create something to run there's ways of doing this in various IDs as well this is all being done at the command line I really wish I had had time to discuss how to do this in Karma but there is this I do have in the notes here using Karma in the AngularJS tutorial and I show an example of how to use Karma to run all the tests in the tutorial I'm outdated I'm really just using the tutorial as a means of running a bunch of tests and then I created this hello world so that we could see a custom implementation of using Karma I'll upload my files and specify where they are inside of this presentation later so that you'll be able to download them and then continuous integration of course is very important so all you have to do is specify your GitHub repository or wherever else your repository is and basically the moment you check your code into GitHub your Jenkins server will be triggered to check out the code, run all of your tests and integrate them together if the tests pass and potentially even deliver the actual software live as a consequence of the tests going green and this is part of the agile engineering disciplines that will get you to the two star level thank you very much, my name is Daniel Zen I'm going to stick around and answer questions I just know that it's 12 o'clock so in case I need to vacate the room I'm available for questions, thank you until somebody kicks me off the stage I'll answer questions from here how I selected what with the test oh yes, sure, let me go back to that so basically I just I just specified a portion of the DOM I wrote it explicitly here now I could actually write a piece of JavaScript that can get compiled by the angular compiler and so what's happening the reason why we have these custom directives in Angular is because it's actually being compiled by JavaScript JavaScript is actually walking the DOM and looking for these new directives and transferring them I do need to step down though so I'll come and answer questions separately thank you, no problem like I said until I got kicked off and that was it, thank you