March 2016 Archives

cpanparty is over

Well, it was a great party but .. It seems everybody needs to get home, as home is better place than being a guest somewhere ... as Russian would say ;)

But to be serious I am going to close cpanparty project as:

  • I don't have much time to write new test cases for existed CPAN module and it seem nobody wanted to join this process

  • My initial idea behind sparrowhub was to create a repository of reusable test / monitoring suites to match various life practical cases. CpanParty is a bit different - this is specification by example / test descriptions of existed CPAN modules. Still thinking that idea is quite interesting I am going to remove cpanparty plugins from sparrowhub to keep it clean and dedicated to initial purposes so not to confuse user asking how can I use test cases for Dancer2 or Mojlicious or other great web frameworks in my daily test/monitoring tasks?

So farewell for CpanParty!

As result:

  • cpanpatry plugins will be removed from sparrowhub index
  • plugins source code will remain on my github repos though
  • let'me know if for some reasons you want to resurrect or start new cpanparty tests for some CPAN distributions ....

SparrowHub - a repository of reusable testing/monitoring suites

Hi all!

SparrowHub - is a test/monitoring suites repository. SparrowHub repository contains collections of reusable testing/monitoring suites which are also called plugins. These are test suites for various use cases. From testing web services to checking disk available amount on your server. Sparrow suites are runnable via console script called sparrow which produce TAP output. It could be used in whatever monitoring , testing task and could be easily integrated into existed monitoring / deployment / configuration / automation systems. Sparrow plugins to be written on outthentic DSL and to be extended by Perl.

I have just added two 5 minutes tutorials for those who:

  • wants just to use sparrow suites in monitoring / testing purpose
  • wants to develop new sparrow plugins

Spek - test oriented web framework

Recently keep playing with TDD and swat I have created a small web framework based on Kelp and swat.

The essential features of this framework named Spek are:

  • it's a Kelp wrapper so most anything you could do with Kelp you do with Spek ( there some limitations though )

  • it's a test centric framework - to implement route/controller you have to define swat test for it first, this is by design. Unless you have a test for your route, an application does not "see" this route. So tests here having a dual nature one for testing , and secondly to act like "placeholders" - for http endpoints definitions . It also could be called "embedded testing" in a sense that having tests meaning having routes definitions, so to start add new route/controller you necessarily need to create a test for it first.

  • well, not all is that smoothly as it sounds (-; , I just took Spek for a spin and want to see what is going to be ...

  • If such a theory sounds quite "obscure" for you, you may take a look at real example at Spek documentation.


The possible usages of Spek are:

  • for web developers - quick web applications prototyping
  • for application architects - quick specification as test development , when Spek application acts like prototype for real production system, and both Spek and production application confirms the same test suite comes with Spek

swat helpful info added at swatpm.org

Recently to help users understand how to use swat, I have added some useful info at swatpm site :

  • a detailed hello world example

  • a FAQ page answering to some potential questions about swat


PS the information on swatpm will be updated

cpanparty updates

Hi!

This is cpanparty current list:

  • Kelp 0.9071
  • Dancer2 0.166001
  • Mojolicious::Plugin::Vparam 1.4
  • Dancer2::Plugin::Ajax 0.200001
  • Dancer2::Plugin::Res 0.03
  • Plack::Middleware::StackTrace::LinkedSource 0.12
  • Raisin 0.63
  • Dancer2::Plugin::Feed 1.160550
  • DateTime 1.25
  • Test2::Suite 0.000022
  • Mojolicious 6.55
  • Dancer2 0.166001
  • Dancer2::Plugin::Auth::Extensible 0.502

Other improvements:

  • colorful html reports

-- Regards

Alexey

continuous integration using sparrow tool chain

continuous integration using sparrow tool chain

Sparrow is a tool to automate testing infrastructure. Automated testing is essential part of continuous integration processes as it provides fast feedback on cases when something goes wrong.

Consider simple example of how sparrow could be used to build up some basic parts of your infrastructure.

web application development

We have a simple Dancer2 application we are going to deploy on development environment:

app.psgi

#!/usr/bin/env perl
use Dancer2;

get '/' => sub {
    "Hello World!"
};

dance;

Let's keep source code at git repository:

git init
git add app.psgi
git commit -a -m 'my web application'

git remote add origin https://github.com/melezhik/webapp.git
git push -u origin master

development server

We are going to deploy application on dedicated server used for development environment:

ssh dev.server
git clone https://github.com/melezhik/webapp.git
cd webapp
cpanm Dancer2
plackup

In these lines we fetch source code from remote git repository and run dancer application. Good so far. These steps could be automated in various ways ( jenkins, crontab , whatever your favorite CI tool ).

Last command should emit following:

HTTP::Server::PSGI: Accepting connections at http://0:5000/

Which means our application is running.

building up test harness

As we need to ensure that app is running correctly after being deployed we have to add some integration tests for it. With sparrow it is as simple as writing a few lines of code:

git init # let's keep test suite case under git

echo 127.0.0.1:5000 > host

nano get.txt
    200 OK
    Hello World!

echo '{}' > sparrow.json

echo "requires 'swat';" > cpanfile

git add .
git commit -a -m 'basic test suite'
git remote add origin https://github.com/melezhik/webapp-basic-check.git
git push -u origin master

Now when we are done with creating a very simple test suite let's go to development server and create some check points:

ssh dev.server
cpanm Sparrow

echo "basic-check https://github.com/melezhik/webapp-basic-check.git" > ~/sparrow.list      
sparrow index update
sparrow plg install basic-check

sparrow project create webapp
sparrow check add webapp basic
sparrow check set  webapp basic basic-check

sparrow check run webapp basic

Output of last command will be:

# running cd /home/vagrant/sparrow/plugins/private/basic-check && carton exec 'swat ./   ' ...

/home/vagrant/.swat/.cache/30818/prove/00.GET.t ..
# trying ... curl -X GET -k --connect-timeout 20 -m 20 -L -f -D - '127.0.0.1:5000/'
ok 1 - server returned successful response
ok 2 - output match '200 OK'
ok 3 - output match 'Hello World!'
1..3
ok
All tests successful.
Files=1, Tests=3,  0 wallclock secs ( 0.03 usr  0.00 sys +  0.04 cusr  0.00 csys =  0.07 CPU)
Result: PASS

Ok, we see that our tests succeed and we can continue with development.

adding new feature to web application

Let's add authentication to your application:

app.psgi

#!/usr/bin/env perl

use Dancer2;
use Dancer2::Plugin::Auth::Tiny;

set show_errors => 1;
set session     => 'Simple';


get '/' => sub {
    "Hello World!"
};


get '/public' => sub { return 'public area' };

get '/private' => needs login => sub { return 'private area' };

get '/login' => sub {
    session "user" => "Robin Good";
    return "login and to back to " . params->{return_url};
};

get '/logout' => sub {
    app->destroy_session;
    redirect uri_for('/public');
};

dance;

Let's create a check list we need to ensure:

  • when user hits /public route he sees 'public area'
  • when user hits /private route for a first time he gets redirected to /login page and then gets a session cookies
  • when user hits /private routes for a second time he sees 'private area'

Now create another suite case for the stories above, we are going to keep under another git repository and then deliver tests as another sparrow plugin as we did with the basic suite case:

creating test suite skeleton

git init
echo 127.0.0.1:5000 > host
echo '{}'> sparrow.json
echo "requires 'swat';" > cpanfile
git add .
git commit -a -m 'authentication test suite'
git remote add origin https://github.com/melezhik/webapp-auth-check.git
git push -u origin master

public area test

mkdir public

nano public/get.txt
    200 OK
    public area

private area first time

mkdir private-first-time
nano private-first-time/hook.pm

    run_swat_module( GET => '/logout' );
    run_swat_module( GET => '/private' , { auth => 0 } );
    set_response('done');

echo done > private-first-time/get.txt

mkdir logout/
echo swat_module=1 > logout/swat.ini
echo 200 OK > logout/get.txt

mkdir private/

nano private/swat.ini

    swat_module=1
    curl_params="-b ${test_root_dir}/cook.txt"

nano private/get.txt

    generator: [ module_variable('auth') ? 'private area' : 'login and to back to' ]

private area second time

mkdir private-second-time
nano private-second-time/hook.pm

    run_swat_module( GET => '/login' );
    run_swat_module( GET => '/private' , { auth => 1 } );
    set_response('done');

mkdir login/

nano login/swat.ini

    swat_module=1
    curl_params="-c ${test_root_dir}/cook.txt"

echo 200 OK > login/get.txt

And finally we can commit changes to git and push them to remote.

git add .
git commit -a -m 'authentication check test suite'
git push

testing new features

As we did with basic test suite we now are able to run tests for authentication feature:

ssh dev.server
echo "auth-check https://github.com/melezhik/webapp-auth-check.git" >> ~/sparrow.list      
sparrow index update
sparrow plg install auth-check

sparrow check add webapp auth
sparrow check set  webapp auth auth-check

sparrow check run webapp auth

The output of the second test suite will be:

# running cd /home/vagrant/sparrow/plugins/private/testapp2 && carton exec 'swat ./   ' ...

/home/vagrant/.swat/.cache/1085/prove/private-first-time/00.GET.t ...
# trying ... curl -X GET -k --connect-timeout 20 -m 20 -L -f -D - '127.0.0.1:5000/logout'
ok 1 - server returned successful response
ok 2 - output match '200 OK'
# trying ... curl -X GET -k --connect-timeout 20 -m 20 -L -b /home/vagrant/.swat/.cache/1085/prove/cook.txt -f -D - '127.0.0.1:5000/private'
ok 3 - server returned successful response
ok 4 - output match 'login and to back to'
ok 5 - server response is spoofed
# response saved to /home/vagrant/.swat/.cache/1085/prove/xDQuPGlVog
ok 6 - output match 'done'
1..6
ok
/home/vagrant/.swat/.cache/1085/prove/public/00.GET.t ...............
# trying ... curl -X GET -k --connect-timeout 20 -m 20 -L -f -D - '127.0.0.1:5000/public'
ok 1 - server returned successful response
ok 2 - output match '200 OK'
ok 3 - output match 'public area'
1..3
ok
/home/vagrant/.swat/.cache/1085/prove/private-second-time/00.GET.t ..
# trying ... curl -X GET -k --connect-timeout 20 -m 20 -L -c /home/vagrant/.swat/.cache/1085/prove/cook.txt -f -D - '127.0.0.1:5000/login'
ok 1 - server returned successful response
ok 2 - output match '200 OK'
# trying ... curl -X GET -k --connect-timeout 20 -m 20 -L -b /home/vagrant/.swat/.cache/1085/prove/cook.txt -f -D - '127.0.0.1:5000/private'
ok 3 - server returned successful response
ok 4 - output match 'private area'
ok 5 - server response is spoofed
# response saved to /home/vagrant/.swat/.cache/1085/prove/hvtwlrTqEZ
ok 6 - output match 'done'
1..6
ok
All tests successful.
Files=3, Tests=15,  0 wallclock secs ( 0.03 usr  0.01 sys +  0.17 cusr  0.01 csys =  0.22 CPU)
Result: PASS

Examining your test infrastructure

Running project show command one may obtain available check points for webapp project. It is handy when eventually a lot test suites come in here.

sparrow project show webapp
[project webapp]

    [checkpoints]

      auth
      basic

Summary

Sparrow tool chains has following features:

  • integration tests suites are decoupled from application code

  • tests could be grouped by types/environments and developed/delivered as dedicated test suites - aka sparrow plugins

  • sparrow test infrastructure is easy to bootstrap on different environments (dev,test,prod) - everybody involved is able now to run desired test suite with easiness

  • swat output is intended to simplify debugging/troubleshooting process, in most cases you just rerun curl command ( against tested server ) with parameters extracted from test output.

PS

paper source code

the source code for this post could be found here

code examples :

About melezhik

user-pic Dev & Devops --- Then I beheld all the work of God, that a man cannot find out the work that is done under the sun: because though a man labour to seek it out, yet he shall not find it; yea further; though a wise man think to know it, yet shall he not be able to find it. (Ecclesiastes 8:17)