Saturday, December 20, 2014

The last time I wrote about RavenDb was two years ago, RavenDb is a great documentDb that has changed a lot since then and now has clients for C#, Java, Python and Node.js. In this lecture Ayende Rahien demonstrates some of the "Wow feature" from the new RavenDb 3.0 version.

Great TED lecture that shows how our body language affects the way we think about ourselves, the impression we create on others and basically how it shapes who we are.

So next time you will be facing a job interview, a presentation you are giving or anything you want to be awesome at remember: a couple of minutes before that job interview stand in a "victory position"

Saturday, December 13, 2014

In
the previous post we understood that testing only the UI logic is not enough
and that manually testing the layout across all the platforms that our
application supports is impossible. We need to automat it and add it to our continuous
integration process.

What is Automated Visual Layout Testing?

*Later
I will introduce a platform that automates the whole process, but first some
basic concepts.

Baseline

In
order to verify that our layout is correct we need a "baseline" – pictures
of our different website/application pages/windows. Those picture are
"print screens" of the layout as it supposed to be presented. After
we manually verify that the layout is correct we set them as
"baseline".

Image
Comparison

From
now on each commit will trigger a comparison between the new pictures of the
application and the baseline in order to check whether the commit's changes
changed the layout. The comparison is not as simple as it sounds, if you try to
compare "pixel to pixel" you will see that a pair of identical
pictures are not really identical.

Take
a look on these 2 pictures:

This
pair of pictures is a close up to the "the" word in the sentence. The
pictures look almost the same but if you look closely then you will see that not
all the pixels have the same color or the same brightness. However then you
zoom out and look at the "the" word in the sentence it will look absolutely
the same. Those differences accrue since the browser/the operation system doesn't render the pictures the same way, it depends on different parameters that I don't want to talk about them in this post.

More examples:

Conclusion:
Two identical pictures to the human eye are not really pixel to pixel identical.

That makes image comparison a lot harder. Luckily there are enough "smart"
image comparison algorithms and tools out there, one of them is a platform called
"Applitools eyes". More about it in the next post.

Wednesday, December 10, 2014

In my postThe
Pyramid of Tests I introduced the different levels of testing that you
should have in your application. In this post I want to focus on the UI testing
phase.

UI Testing

In order to fully test your application you have to write unit tests,
system tests and integration tests to fully cover you business logic and the
systems workflows, however that's not enough. You also have to test the UI of
your app, to verify that it displays the right output, check that the different
UI elements behave as expected and so on.

In the past we used to manually test it – click some buttons, enter an
input and assert that the output was as expected, nowadays we use automatic UI
testing frameworks like CodedUI, selenium and protarctor. These frameworks
allow us to record the actions we used to perform manually and run them
automatically. Now our application is fully tested. That’s all we need right?
Wrong!

Checking only the UI
logic is not enough!

Even if the logic is correct it doesn’t mean that the application is
ready to production.

This is a screen shot from a website where the graph width didn't match
the screen size any more.

Another example is a bank website where all the letters in the site
turned into gibberish. UI Logic tests will not find those errors. Obviously we cannot
allow our self to have an application with these errors in production. That
means that besides our UI Logic tests we also need to test the Layout.

In order to fully verify that the layout is "correct" we need
to test it on all the possible browsers – Chrome, Fire Fox, IE, Opera and on
all the possible screen sizes – PC, Tablet and the different mobile devices.
You do it since the CSS that suites Chrome doesn't look the same in IE and the
HTML tag that you've used on one platform behaves differently on another one.

Let's say that my
last commit included some CSS changes, those changes didn't affect any logic
however they might ruin style in some place in my application, my UI Tests will
not find it since they check the logic and not the style itself.

As you can see the tests matrix is too big and it is not possible to
manually test it.