Welcome back.
Hopefully, everybody's energized and hydrated and alert once again.
Hopefully, nobody ate too much.
Don't fall asleep.
We have some really good talks lined up right now.
So Ran and Lior are going to talk about their open source (indiscernible) that they have
developed that helps mobile apps test themselves.
>>Lior Reuven: Thanks.
So hi, everyone.
My name is Lior.
And joining me today, Ran.
We are from HP Software, what was actually, a while back, sometime ago, (indiscernible)
Interactive.
And I wanted to discuss about catjs, a new platform for mobile app testing.
While Ran sets up our live demo, hopefully, I would like to give a little bit of a history
about why we created it, what was the motivation for creating yet another testing framework.
So it all happened when I was asked to create a new project, a new product inside HP Software.
That's my day job, I incubate new projects.
And I did what I usually do.
I got budget for a small team.
I assembled a small team.
We called it the A team, because we had four guys.
And set a strategic direction for the product.
I don't know which was progressing really nice.
After a few weeks, we had a working MVP.
And there were two major factors for having that product, that MVP.
First, we had a killer pipeline, which enabled us to push code and experiment a lot.
And the second thing is that we had a great team culture.
It was based on trust, on quality, on fast feedback.
Again, enabled us to push code very, very fast and achieve good results.
So everything was looking bright.
And then we found out that we made a small mistake, that most of the users will consume
the product from mobile and not desktop.
Well, big surprise.
So our designers were happy; right?
They redesigned the whole thing, made it responsive to support all the different form factors.
The developers were happy.
They got some new devices.
And we started implementing the application.
And then we start testing the application.
And we are failing.
We are stuck.
We just couldn't understand what -- the quality of the product and the application.
Too many devices, too much time, and not enough tools.
So we did what most engineers, good engineers, do.
We started to research and identify the most common framework software.
And we narrow it down to two or three and start implementing this.
But what we found quite fast, that we are spending -- sorry, investing, sorry -- a lot
of time.
[ Laughter ] Was investing a lot of time on the infrastructure,
on the test, on flaky tests, as a lot of people mentioned here.
And at a certain point, we understood that, well, most of the time it's going on the test
frameworks, on setting up the test and not testing.
It even got to a certain point that we were developing or investing more time on the frameworks
or on making it work than developing the application.
So we took a decision, and instead of adjusting our developers to the framework, we put the
developer in the center and tried to enable and empower him to write tests much more easily
and much more fast.
So to do it, we had to overcome a few challenges.
The first challenge is, our developers just wanted to write test and that it will run
on any device, any operating system, any browser.
They didn't want to do any configuration.
Just push code and have it run on any device, any browser, any way.
The second challenge was to make it simple, readable, and reliable.
Again, flaky test, maintaining the infrastructure, they didn't want to focus on that.
So we handled that.
And, of course, we also made the code itself, the test code, based on the same code based
of the application, which in our case is JavaScript.
I'm a big believer in HTML5.
That's the project that was focused on mobile Web.
Third, we wanted it to fit into our existing life cycle.
We already had a good pipeline.
We didn't want to change it.
We didn't want to create a new standard.
So we wanted to stick to the existing standards, like unit test, and how you report it and
so on and so on.
And last, we wanted it to be extensible and open.
So if a certain developer doesn't like the assertion library that we have in our framework,
they can just plug in another assertion library and it will be very (indiscernible) and also
enable him to add additional test types, for example, not just functional test, but also
performance test or usability.
So our architecture, which is plug-in-based, enabled him to do so.
So a little bit about catjs architecture on a very, very high level or how it works.
It has three steps or three components.
First, you write scraps.
This is a new approach for testing where you write your code, your test code, side by side
with your code.
Scraps is small building blocks, set of functionality, which you can write and test.
Once you write your test or you write your scrap, you then run catjs.
Catjs is better known JS.
Basically, what it does is scan your project, identify the different scraps, inject the
testing code into application, rebuild application as a test deployment, push it to the device,
and then execute it and, of course, report back to your central repository of results
if (indiscernible) other CIs.
So now Ran will demonstrate how we can have a demo in less than five -- less than five
minutes, I hope.
>>Ran Snir: Hi, everybody.
For those who didn't catch my name, I'm Ran Snir, and I am one of the developers of catjs.
I want to show you an example with catjs that will give you a small taste of what catjs
is all about and how easy and fast it can be sometimes to build a full automation of
your mobile Web application.
We need to switch to the slides, please.
>>Lior Reuven: Can you switch back to the slides.
>>Ran Snir: Okay.
Thank you.
But before we will start, we need to set up our environment.
So as Lior said, catjs is based on no JS technology, but simply by clicking and installing catjs
will install catjs as a command-line tool in your environment.
And catjs, we call it (indiscernible), will be happy to create and execute your test deployment.
We have a new approach for testing.
This is based on Scrap.
Scrap is a small comment annotation that you need to add to your application code that
will be later on in -- with the catjs process, will be injected as a small functionality
unit in your test deployment.
Collecting all the scraps together will create a full automation of your mobile Web application.
This will add ability to the application to test itself instead of other framework, as
you know.
Now, scraps are pluggable.
You can use the built-in plug-ins that we already created for you, like the JS assertion,
if you need to test and check things, (indiscernible) and the most common one is the jQuery mobile.
But if you really like, you can create your own customized plug-in for your own needs.
But Scrap can do a lot more than regular DOM manipulation.
It can also manipulate JS object.
As you see, the scope of AngularJS, I think you will recognize that, that's (indiscernible)
from Lior to Ran Snir in the test deployment.
Now, for today's event, I have created kind of example that will show catjs abilities,
if we can switch to the -- my computer.
>>Lior Reuven: Great.
>>Ran Snir: Lior talked about continuous delivery.
Now, in our team we have created an application that check GPS location.
But we have many trouble checking that.
So we found a solution with catjs, and I created for today the application "I am at."
This is the kind of a game that you need to guess where you are while the application
reveals where you really are.
Now, after 24-hours of flight from Israel, Tel Aviv, to here, I can really relate to
that because I woke up in my hotel this morning and I didn't have any clue where I am, so
luckily, I have this application.
So I know that today I know I am in GTAC, so we will click Google Kirkland, and click
go.
Now two maps will be revealed.
One will be the guess where I think I am, and the other will show where I'm really at.
So, simple.
Now, let's create this automation with catjs.
So we need to add a couple of scrap to the application code.
Let's dive into our code.
We have the input element.
We need to set that we are at Google Kirkland.
So I am setting this, simple first step.
Now let's create another scrap.
We need to click the go button.
Now I am adding another scrap by simply using, again, the jquery mobile plugin to click the
go button.
Okay.
I finish with that.
I need to check my result.
I need to check that point A, my guess, and point B is the exact same point at the exact
same location.
So I am taking the scope of AngularJS with the point A and point B and I'm using that
session plugin with the Google Maps API.
And I think that radius of five kilometers is about a correct guess.
And the test will succeed; otherwise, it will fail.
Now we need to run it.
So in the meantime, when Lior explained about catjs, I created a small mobile lab over here
with a few devices that you will see just now.
And now we will run the test.
We will see that on all the devices, also on my laptop.
And we can see cat UI on the right corner that shows that setting the text, clicking
the go button says -- okay, about the location.
>>Lior Reuven: Sorry.
>>Ran Snir: Okay.
Department manage to do that.
Okay.
Now we can see that one map is okay.
We see the same location.
And the other two devices, I have bug on them.
The GPS location is not working so well.
So those results will be -- later on will be I am ported to Jenkins CI, and it's simple
as that.
Five minutes it took me, and I think it's wonderful in this time.
Now let's move back to the slides, and we will finish, wrap it up.
Actually, catjs is an open source, and we need your help to take action in this growing
community.
We want you to download us from github, all the npm repository, and we will try to help
you as much as we can.
Also, we are giving prizes this month for selected applications with catjs, so try us
out and thank you for listening.
[ Applause ] >>Sonal Shah: Great talk.
Thank you so much.
Do we have any live questions in the audience?
>>Lior Reuven: And thanks for your hot spot.
>>> Hi.
It's a greatest automation tool.
I think -- I have a few questions that I wrote down while -- during the presentation.
So doesn't the code base increase the size of the whole application?
Given that it is running on the device.
S Usually, you want the test to reflect what
the code is doing.
>>> Yeah, in general we have test codes separate from the dev code, like our production code.
So that's why I'm asking this.
>>Lior Reuven: And there's also a second option that you don't need the test to the code.
we have had that request before, so there is also the possibility to do it outside of
your code.
So, there is that configuration.
You know, it's just a new approach.
That's what we are feeling.
It worked for us to have the tests side by side to the code and that worked for us.
>>> And is there any way to actually, when the code has been shipped, take out the tests
automatically?
>>Lior Reuven: No, no, you can take it outside.
No problem.
>>Ran Snir: When you minified your project, all the annotations are removed.
>>> And why is it restricted to devices only?
>>Lior Reuven: It's not.
It's not.
I think why we created it, is because we had problem with mobile Web.
It will work on Web.
I think that in most cases, the automation in Web is commoditized already.
There are a lot of frameworks, so already a lot of suites are running.
And I don't think people should change that and rewrite all the tests.
>>> Okay, okay.
>>Lior Reuven: But having new stuff for developers or something which is much easier or agile
and simple, I think that's the direction to take.
>>> And the last one is you mentioned a URL for the github.
Is it like go there and do what?
>>Lior Reuven: You just download it, like Ran said from the nodejs repository or from
github.
>>> And start using it?
>>Lior Reuven: Install and that's it.
There is readme and getting started in our site
>>> Is it integrated with current applications?
Is it easier or difficult other than the steps to follow to integrate this tool into current
applications?
>>Lior Reuven: To current applications, it should be simple.
That's a lot of focus that we had, not changing your ecosystem but just fitting it into the
existing one.
So shouldn't be a problem.
>>Ran Snir: You just saw the steps.
Add scarps to your application code and it’s done.
So simple.
Five minutes as we promised.
>>> All right.
Cool.
Thanks.
>>Ran Snir: Thank you.
[ Applause ]