>>Tony Voellm: So next speaker up is Vojta Jina. He likes funky jazz and he has a very
action packed talk. He is probably going to run right to the middle or to the end so he
probably won't have questions and we'll just go right into the next talk after he's done.
So here you go. Great. Thank you.
>>Vojta Jina: Thanks. So this conference is about automation and
testing; right? So I assume you guys are one of those crazy people who try to automate
everything; right? Even if it takes more time than doing it manually,
we write a script for it because that's what we believe in; right?
And that's cool. I mean, in this our team, we are the same. We basically try to automate
everything. So for simple things like automatic deployment
to the Web site to things like, you know, we have C.I. server and whenever I push some
code to github, it automatically builds Angular, runs all the tests on different browsers and
screams at me if it fails. Or every release has a change log. You know, that's basically
a list of changes, like list of new features, back fixes, breaking changes. And you know
what? We generate even that. Like we have a convention for git messages, and then there's
a script that basically generates the script based on the git history.
Or my favorite is Angular docs. So let me actually show you the docs. If you go to docs.angularjs.org,
there is Angular documentation, and this is, for instance, API docs for NG click, which
is a directive in Angular. And down here, here is an example. Here is the source code
for that example, and then there is a live preview or like demo where you can actually
play with it and see how it works. Right? Cool. I mean, of course the whole documentation
is generated automatically. But the thing I want to show you is the second
tab which says end-to-end test. And that is basically an example for you how you can possibly
test such a code, like end-to-end test for that. But what do we do with that, we extract
all these tests, and then we run them as a part of the build. Let me show you that.
So it looks something like this. And you can see, it's basically going through
the whole documentation and checking whether all these examples still works. And this is
really awesome, because before we did this, it would be, like, all the time it would happen,
like someone would email me, like, hey,man, your docs example for HTTP doesn't work. And
I would be like, oh, cool, I didn't even though that was an example for that. But now with
this, you don't have to think about it. Like if -- And if you break it, it will scream
at you. So we basically try to automate everything.
Let me kill this guy. And we do testing a lot. We rely on testing
a lot. And, therefore, we want to make sure that our testing story is really efficient.
And that's pretty much why we did Karma, which is, I would say, a test runner that fits our
needs because we made it for ourselves. And that's what I want to show you now. I want
to show you this test runner that we use to test Angular and pretty much to test any JavaScript.
So let's do demo. So Karma is an MPM package so assuming you
have no JS, you can install it through MPM install Karma. And then first thing you need
in order to start, you need a configuration file, which is basically for Karma to know
about your project, basically where the files of the project, what browsers you want to
use, which testing framework you are using and stuff like that.
To make it simple, you can generate -- you can generate this config file by Karma in
it and it will ask you a couple questions like what testing framework you want use,
and which browsers and stuff like that. And it will generate the config file for you.
Or if you are using Grunt -- do you guys know GruntJS? It's a really awesome task runner
for JavaScript. So if you are using Grunt, there is a Grunt plug-in for Karma that allows
you to configure Karma through Grunt and you don't need this configuration file at all.
All right. For this demo, I'm going to be using Angular code base which already has
this config file. So we can start it. I can do Karma start, and what's happening
in the background, it starts a browser that I told in the config file that I want to be
using, and, you know, we can forget about the browser for now. But the important thing
is that there is a real browser in the background that Karma will use to actually execute the
task. And that's something I want to actually talk about because, you know, you can execute
-- you can test JavaScript even without browsers. You can do like NodeJS and Rhino, but for
us it was really crucial to use real browsers because if you know Angular theirs there's
tons of components and custom directives and stuff, and it's there are DOM manipulations
and we need to DOM API. We need to test these things, so we need real browser for that.
Plus, there are so many inconsistencies between browsers, and JavaScript itself as a language,
it's not that bad it's pretty consistent, but the DOM API, that's where most of the
issues are. So again, for us, we need real browsers.
Plus, third thing, there is good advantage, once you are using real browsers, it basically
communicates through HTTP and Web circuits, so it means you can use any browser, like
you can test your phone, your tablet, TV, play station, whatever you want.
Okay. Let's go to source code.
And another thing that's happening in the background is that Karma is now watching all
the source files of my project. And whenever I -- here is like cache factory and service
in Angular, it's not that important what it is, but I am going to save the file. Just
press command S and you can see that Karma immediately see that and starts executing
all the tests. And you can see it executed over 1800 of unit
test in, like, three seconds on the real browser; right?
And I mean, three seconds is not bad, but if you have huge project, it can be more.
And our goal is to get this instant feedback so that I can run these tests all the time,
because what I really do during development is, like, I want to run these tests on every
save. And that's why we have this feature, we call it D describe in i8. Do you know,
on the right side, that's my test. I'm not sure if you recognize the syntax.
It's a Jasmine testing framework. So I should mention that Karma is agnostic of testing
framework. You can use it with any testing framework you like, pretty much. There is
adapter for Qunit, Mocha, Jasmine, Node unit and stuff. We are using Jasmine. That's why
this example is in Jasmine, but you can use anything else. And describe in Jasmine basically
means like defining a test suite, a list of suites, and it means defining a single test.
And what I can do, I can focus these things, so I can put D describe, and now when I say,
if you can see, it immediately executes just this suite. So it's even faster; right? Like
now it executed only 24 of these 1800 unit tests and it was like, I don't know, a few
milliseconds. And so the goal isn't -- The thing why this
is important is that it gives, like, a new work flow. It's basically like using test
as a development work flow, where you basically, you can stay -- you can stay in your text
editor and you don't have to move back and forth within browser and your text editor
to see how things work. Because what I can do, let's say in this test I can do, I don't
know, console.log, cache 1, whatever it is, maybe give me size. It gives me error, undefined,
whatever. So there is no size. So I guess theirs there's info. Right.
And the thing is that I just saved the file and I immediately see in the console the result
from the real browser. So I don't have to go to the browser to do these things, you
know. And this is really important for the work flow because you can stay in the browser
-- sorry, in the text editor. One more thing that I want to mention is that
there is no -- there's no support from text editor. Like I'm using Sublime. You can use
EMACS, Vim, whatever you want, because the only thing the text editor in this work flow
does is saving files. And I've got one more thing I want to show
you, and that's debugging. Because what I can do, I can, inside this code, if I want
to actually use real debugger, I can do this, and guess what? I can go to the browser that
I have somewhere in background and I have debugger, you know? I can watch werewolves,
I can see call stack, I can step into functions. And this is something, this is not feature
of Karma. That's just the browser have. Like most of the modern browsers, they have debuggers,
so it only allows you to use that. And again, you don't need any support from the text editor
to do that. If you happen to using something like Web
Storm or some better IDEs, you can even configure it to do this debugging directly from Web
Storm so you can put break points and stuff, and you even don't have to leave your IDE
for debugging. All right. I think that's -- You know, there
is tons of other features, like it can do code coverage, it can preprocess files so
that you can develop -- like you can use coffee script and it will compile coffee script on
the fly. There's a Dart plug-in for testing Dart. All kinds of other plug-ins. But I think
the most important feature is the work flow, that you can run tests and instantly see and
instantly get the feedback. So that's the main thing so that's what I wanted to show
you. If you like it, you can go to github, check
it out. It's open source, so send us pull request.
And, as I said -- we're probably running time pretty soon, so I'm not sure if we're going
to have questions, but I'm going to be here today and whole tomorrow so find me and I'm
more than happy to talk to you guys about pretty much anything.
>>Tony Voellm: Thank you, VOJTA. Actually, I think we may have time for one question.
[ Applause ] >>Tony Voellm: I have to say I was really
happy that you only typed Karma start and you never typed Karma end. I was a little
worried if that was going to happen because --
>>Vojta Jina: Oh, well, I do control. >>Tony Voellm: We can take a live question
if someone has a live question, or we can go to the Dory. Or we can move ahead.
Okay. I've got a question here, the number one question. You probably saw this, actually,
in the UI too. It says why was Karma renamed from Testacular.
>>Vojta Jina: Okay. I didn't expect that question at all.
[ Laughter ] >>Vojta Jina: I don't think I want to answer
this question -- [ Laughter ]
>>Vojta Jina: -- on the stage, but the good thing is that now typing Karma is way faster
than Testacular, because especially if you are using regular keyboard layout it's really
easy to type. [ Laughter ]
>>Tony Voellm: Great. All right. Thank you, VOJTA.
>>Vojta Jina: Actually, can I -- I think I would like to -- I would like to close this
with a quick story. I think we have two minutes so I can do that.
>>Tony Voellm: 30 seconds. >>Vojta Jina: 30 seconds? I will do it quickly
because I am really happy about that thing. There's a project called YouTube on TV. It's
basically if you have play station 3 there's a YouTube app and it's written in Angular,
and a few months ago we were helping the team to debug some performance issues and I noticed
that they had, like, 90 or 100 unit tests. And I was like, wow, that's not many. So I
asked them, guys, why don't you write more tests? And when they showed me, like, how
painful it was to, like, add a new test in their suite and how slow it was to run these
tests, I was kind of like, okay, I understand that. And so the next week I helped them to
set up their environment with Karma and we actually set it up to run it on real play
station and it was really cool because in a few days, maybe a week I got an email from
Tyler, one guy from team, and he was, like, "Vojta, this shit is awesome! Like, it completely
changed our life. We test drive everything now!" And believe me or not, but after a week
or something, they had over 400 unit tests. So it basically took them about a year to
write 100 tests, and then they basically wrote 300 tests in just a few days.
And the point is that, you know, you should spend time figuring out your work flow and
your environment. Find the right tools for you. It doesn't have to be Karma. I don't
care. Use whatever works for you guys. But it's so much worth it to spend the time because
once you do it, it will save you tons of time. Cool. So thank you.
>>Tony Voellm: Thank you. Thank you. [ Applause ]