Once upon a Friday

Are you a smart web developer using Mojolicious, Dancer2, Kelp, Limper or just CGI ? Sure, yes you are! ;-) You have just finished yet another web application ready to get deployed and awaited with impatience by your customers. All your 't/' are fine, you for sure use Plack::Test or similar tools to tests your application not only in internal but external way. Everything is going to be fine, even though it's Friday today and is not probably good time to make a release, but you so anxious to see a results and get users input, so you are going to talk to John - devops guy and send him a git URL where your source code lives in so he could start the deploy procedure ...

... But, yes, there are some "hurdles" always. John kindly asking you to provides some monitoring capabilities for your freshly baked application, so he could make it sure it won't break on weekend silently without alarming anybody ...

Ah, yeah you talk about monitoring ... ?

"Ah, monitoring John, yes, sure ..." - thoughts have passed in your mind.

"Well John, you could try a curl or check_http or something else and write your own bash script to get this done. It's easy for sure, you only have to take care about cookies get sent back upon successful authentication, you know curl "knows" cookies, you know cookie as well, do you? Also there is a database endpoint you need to call periodically to ensure application does not lost DB connection.

That's it!

And ... yeah, you know the a route for this called GET /database-info ... - Just use it!"

Saying all these phrases you are looking at John's face and have noticed as him is getting unhappy, a moment after you start to realize why.

" Ah, Alex ( this is your name ) - ... Cookies, cookies ... what you are talking about ? Sorry, I am pretty swamped right now, you know a couple of applications coming from next department have been waiting to get deployed since yesterday."

"I am really sorry, but can't do what you talk about right now. What if you come to me on Monday, and we sit together and drop some tests for your application monitoring? You know I'd be happy to deploy it, but I need some tests first ..."

Now it's time for you to be unhappy ...

Swat / Sparrow - Don't be unhappy

Swat is a DSL for rapid web tests development. And sparrow is the tool to make some "glue" to push your swat tests into production.

Let's see how we could use both of these tools to make Alex life more happy and letting him find better collaboration with his colleagues.

Alex's application besides that cool and important for customers, exposes some essential endpoints we have to talk about a little bit:

• POST /login
• GET /database-status

The first one, obviously is for letting user sign in and should be considered as vital part of the application. Upon successfull login server returns session cookie and redirect user to profile page with greetings:

 Hello user! This is profile page

And the second one, is not intended to be accessed by human - as it name hints - but by ... right monitoring script! This endpoint was accidentally named by Alex as `GET /database-info' in his conversation with John.

Upon hitting /database-status we will have:

database is running!

Which means connection between application and database server is perstist and we don't have to worry about it.

Ok, having this we could drop some tests for two routes, in a minimal time and with minimal efforts:

First of all let's create a directory to hold our tests scenarios:

$ mkdir app-monitoring
$ cd app-monitoring

Then let's define mentioned routes:

$ mkdir login/
$ mkdir database-status/

Now, we are almost done. We need to define a content which we expect to get when request the routes.

One for login:

$ echo '200 OK' > login/post.txt
$ echo 'Hello user! This is profile page' >> login/post.txt

And one for database-status

$ echo '200 OK' > database-status/get.txt
$ echo 'database is running!' >> database-status/get.txt

And, yes, our application send cookies back and make http redirect to /profile page upon successful login, so we need to take care about this:

$ nano login/swat.ini
curl_params="-d username=$username -d password=$password --cookie-jar ${test_root_dir}/cookie.txt"

And finally let run our tests manually to see they works:

username=alex password=123456 swat ./ 127.0.0.1:3000

vagrant@Debian-jessie-amd64-netboot:~/projects/papers/blogs-perl-org/app-monitoring$ username=alex password=123456 swat ./ 127.0.0.1:3000
/home/vagrant/.swat/.cache/18844/prove/database-status/00.GET.t ..
ok 1 - GET 127.0.0.1:3000/database-status succeeded
# response saved to /home/vagrant/.swat/.cache/18844/prove/sL6VpL2brR
ok 2 - output match '200 OK'
ok 3 - output match 'database is running!'
1..3
ok
/home/vagrant/.swat/.cache/18844/prove/login/00.POST.t ...........
ok 1 - POST 127.0.0.1:3000/login succeeded
# response saved to /home/vagrant/.swat/.cache/18844/prove/CZEawnHwv_
ok 2 - output match '200 OK'
ok 3 - output match 'Hello user! This is profile page'
1..3
ok
All tests successful.
Files=2, Tests=6,  0 wallclock secs ( 0.02 usr  0.00 sys +  0.10 cusr  0.00 csys =  0.12 CPU)
Result: PASS

Hurrah! We have just succeeded with monitoring script ready to use, but how we deliver it to John?

Little sparrow to ship your monitoring scripts

Well, sparrow is another part of this story. Not that long, as sparrow is easy to set up and use.

In a few words sparrow acts like cpan client for swat test suites. One may package swat tests into sparrow plugin and upload it into SparrowHub - swat test suites repository, so that others could use it.

This is what we need to do ...

First of all let's install sparrow:

$ sudo cpanm Sparrow

Then get registered at SparrowHub and have an API token required for sparrow client authentication.

$ cat ~/sparrowhub.json

{
    "user"  : "alex",
    "token" : "here will be UUID string"
}

And finally upload a plugin for your swat tests suite:

$ cd app-monitoring
$ nano sparrow.json

Sparrow.json file is like Build.PL or Makefile.PL for your swat test suite. It provides some meta information for plugin successfully gets uploaded into SparrowHub.

This is minimal information we need to provide:

$ cat sparrow.json

{
    "version" => "0.0.1"
    "name" => "alex-web-test",
    "description" => "this is a great plugin to monitor alex web application!"
}

OK, we are almost setup. A final step, need to declare CPAN modules dependencies if have any. We are going to use cpanfile / carton for this. A minimal dependency we have here is swat itself, as we run our tests by swat.

$ cd app-monitoring
$ nano cpanfile

require 'swat';

Now we ready to share our plugin via SparrowHub.

$ cd app-monitoring
$ sparrow plg upload

This is the end of Alex's story. And now let's go back to John.

This is a sparrow, John!

Alex said merrily coming into his room. "Now it's really easy to setup monitoring you asked me!"

All that John have to do is to grab his keyboards and type a few commands.

First of all, guess what? yeah - `sudo cpanm Sparrow', as he needs it too!

Then create some monitoring setup.

$ sparrow project create alex-project
$ sparrow check add alex-project brand-new-web-service

Last two command just create a sparrow project for Alex's application and checkpoint called `brand-new-web-service' to run monitoring checks against it.

Then John probably need to install a plugin Alex just uploaded into SparrowHub. No registration required to install sparrow plugins, as it absolutely free stuff:

$ sparrow index update
$ sparrow plg install alex-web-test

Then having plugin installed John need to configure a checkpoint for it:

$ sparrow check set alex-project brand-new-web-service -u 127.0.0.1 -p alex-web-test

Having this means web application will be accessible at http://127.0.0.1 and will be tested by alex-web-test sparrow plguin test suite.

And finally let's set credentials required for tests:

$ sparrow check set_swat alex-project brand-new-web-service

    username=whatever_test_user
    password=test_user_password

Let cron do it's job

Now it's safe for John to put Alex application into production and go to home:

$ crontab -l

MAILTO='john@company.com'

*/10 * * * * sparrow check run alex-project brand-new-web-service --cron

This will run monitoring checks every 10 minutes and in case of errors a swat test report will be emailed back to John.

PS

That's it!

--- Happy new year and have fun tests with Swat and Sparrow!