初めまして、VOYAGE GROUPの李一（@pank7）と申します。
昨年9月末に中国から参りまして、今子会社adingoでエンジニアをしています。すみませんが、日本語はまだ勉強中なので、これから英語でうちのチームの新しいメンバーを紹介させていただきたいです。
Have you and your team ever encounter the situation, or let's say, difficulty of deciding who will be responsible for scenario testing or browser testing before every release day? Seems like our team -- fluct, have been suffering from that once every 2 weeks for quite a long period of time, long enough for us to start to hate that kind of testings, which requires been done by clicking and typing according to certain movement lists -- scenarios, with only hands and without any automation.
What? Why do we hate that? For God's sake, clicking and typing according according to some instructions is not something an engineer should spend his/her precious time on, not even for 20 minutes! Not to mention that people make mistakes all the time. Well, seriously speaking, the most important reasons why we need some one who can do browser testings for us are that we wish to:
- release faster and more frequently,
- release with more automations,
- release flawlessly,
- the last but not the least, be able to release on Fridays.
Thus, we never stopped looking for some one we can count on. However, making browser testings work in the way we want is not as easy as it looks. Some of the obstacles are:
- Javascript's are difficult to test
- We need to emulate movements, such as clicking and typing, not just HTTP GET's and POST's
- There may be too many prerequisites or dependencies for even short testings
- Instruction list changes frequently
- Confirming the HTML elements on every page can be too boring, and people make mistakes easily
Of course we did have some progresses, however not until recently did we find a best one and think this is some one who can satisfy all our requests. Now, ladies and gentlemen, please allow me to introduce you an insanely fast, headless and so reliable member on our team: Ms. zombie.js. Don't be scared, she dose not bite your brains. Let's find out how she does her works.
Overview
Specifically speaking, we have already prepared a movements/confirmations list called scenario, that is something like the following:
- Open URL: http://www.example.com/login, confirm the page has a title called "Example";
- Input something into "user_id" and "user_password" boxes, if the page has two, then click the button called "Login", if the page has one, confirm that the page is redirected to URL: http://www.example.com/top, and that page has a title tag called "Top Page";
- Click a link called "TEST" if the page has one, confirm that the page goes to URL: http://www.example.com/test, and that page has a title tag called "test";
- Click a button called "Click me" if the page has one, confirm that javascript insert an a tag into the page, had text 'TEST', and links to URL: http://test.example.com/
- ...
Before Ms. zombie.js came, we test by doing exactly what's in that instruction list, only now that we have Ms. zombie.js doing the job for us. As Ms. zombie.js does not talk much, never actually, I'm afraid you can not talk to her, if you want know what she can do, you can refer to her homepage.
Ok I forgot to tell you Ms. zombie.js is actually a Web browser emulation robot library built with node.js. But to put it simply, Ms. zombie.js emulates a browser, and emulates it so really that it:
- has history records,
- keeps cookies,
- supports HTML5, XHR,
- and runs javascript's.
"All of that, just like a real browser, happens asynchronously", said her father. Ms. zombie.js has a group of API's which imitates human motions and easy to use. Ms. zombie.js speaks javascripts, CSS selectors and DOM. Thus, we believe Ms. zombie.js is competent in doing browser testings, in fact she did a good job.
So now if we want to test according the sample scenario above, we write the following code (of course we are using some other libraries like vows and assert, at the same time. You don't have to use them if you don't like them). See, things became easier than before, now we can test by only one command:
$ vows test.'s --spec
Pros
We have to admit that Ms. zombie.js is the best browser emulation robot ever, it
- helped us making automatic browser testing become possible;
- helped making testings easier because we can now reuse codes, if you organize your code in an elegant way;
- increased testing accuracy because it makes no misses, theoretically;
- shortened the time spent on testing because of its high speed;
- and gives us more confidence to release on Fridays.
All in all, it overcomes the main obstacles which was mentioned above.
and Cons
Although Ms. zombie.js simulates browsers in a really resemble way, that does not make it a real browser. There can be differences, thus you have to carefully organize you output and fit both Ms. zombie.js and real browsers in your development.
The second thing is that Ms. zombie.js is young and evolving, your testing code may get outdated fast, making it difficult to upgrade your zombie.js library.
And by the reason that Ms. zombie.js is a young lady, she can be buggy sometimes. This link demonstrates an example of a bug we found in zombie. We then report it to its github repository homepage, and it was resolved now.
The End
In conclusion, if you are now suffering from doing browser testings by hands, we'd like to strongly recommend you to hand over that work to Ms. zombie.js. She tests automatically, insanely fast, emulate almost everything that a browser has. Even thought she's not perfect in all ways, she is able to help a lot with your testings and releases, enjoy her!
