With upcoming version 0.2.0 swat removes usage of prove as internal test runner. There are some -minor- breaking changes due to this. For those who uses swat I would recommend to read GH pages docs and in case you'll need help with migration of your project to the latest swat version don't hesitate to contact me.

Regards

Alexey Melezhik

A bits of theory

In this post I am going to show how you can use Sparrow to test Mojolicious applications.

Sparrow approach to test things differs from convenient unit tests approach, practically this means:

• A tested code is treated as black box rather than unit test way where you rely deeply on inner application structure.

• A sparrow test suites are not a part of CPAN distribution ( the one you keep under t/* )

• A sparrow test suite code is decoupled from tested application code and is better to be treated as third party tests for your application

• Sparrow tests suites have it's own life cycle and get released in parallel with tested application

• Sparrow acts like toolchain to choose proper tools and then analyze script output

• IMHO writing sparrow tests sometimes is much simpler and takes less efforts and time, but I don't say you don't need a unit tests but sometime it worths it to take an alternative testing approaches / tools and see the difference , so if you are interested , please read below ...

Ok, let's go to the practical example.

Simple test

A Mojolicious comes with some handy tools to invoke a http requests against web application.

Consider simple mojolicious code:

#!/usr/bin/env perl

use Mojolicious::Lite;

get '/' => {text => 'hello world'};

app->start;

Now we can quickly test a GET / route with help of mojolicious get command:

./app.pl get /
[Sun Dec 11 17:23:38 2016] [debug] GET "/"
[Sun Dec 11 17:23:38 2016] [debug] 200 OK (0.000456s, 2192.982/s)
hello world

That's ok. This is going to be a base for out first sparrow test:

$ nano story.bash

$project_root_dir/app.pl get /


$ nano story.check

hello world


$ strun

/ started

[Sun Dec 11 17:45:28 2016] [debug] GET "/"
[Sun Dec 11 17:45:28 2016] [debug] 200 OK (0.000469s, 2132.196/s)
hello world
ok      scenario succeeded
ok      output match 'hello world'
STATUS  SUCCEED

What we have done here.

• created a story to run GET / against mojolicious application - file named story.bash
• created a story check file to validate data returned from http request.
• finally run a test suite ( story ) with the help of so called story runner - strun

More about stories and check files could be found at Outthentic - a module for execution sparrow scripts.

Consider a negative result here, when test fails. For this let's change a check file to express we need another string returned from calling GET / route:

$ nano story.check

hello sparrow


$ strun

/ started

[Sun Dec 11 18:18:07 2016] [debug] GET "/"
[Sun Dec 11 18:18:07 2016] [debug] 200 OK (0.001237s, 808.407/s)
hello world
ok      scenario succeeded
not ok  output match 'hello sparrow'
STATUS  FAILED (256)

Debugging test scripts

As our test is just bash script it easy to add some debugging facilities into it:

$ nano story.bash

set -x

$project_root_dir/app.pl get /

And run the script:

/ started

++ /home/melezhik/projects/mojolicious-app-smoke/app.pl get /
[Tue Dec 13 13:16:07 2016] [debug] GET "/"
[Tue Dec 13 13:16:07 2016] [debug] Routing to a callback
[Tue Dec 13 13:16:07 2016] [debug] 200 OK (0.000328s, 3048.780/s)
hello world
ok  scenario succeeded
ok  output match 'hello world'
STATUS  SUCCEED

Right now it looks pretty useless but becomes very handy for more complex scripts.

Splitting test suite on many simple tests

As your application grows it comprises many routes, let's how we organize our test suite layout to test them all.

$ cat app.pl

#!/usr/bin/env perl

use Mojolicious::Lite;

get '/' => sub {
  my $c = shift;
  $c->render( text => 'welcome page')

};

get '/hello' => sub  {

  my $c = shift;
  $c->render( text => 'hello '.($c->param('name')))

};

get '/bye' => sub {

  my $c = shift;
  $c->render( text => 'bye '.($c->param('name')))

};

app->start;

Here is the story modules:

$ mkdir -p modules/welcome-page modules/hello modules/buy

# welcome page
$ echo '$project_root_dir/app.pl get /' > modules/welcome-page/story.bash
$ echo 'welcome page' > modules/welcome-page/story.check

# GET /hello
$ echo '$project_root_dir/app.pl get /hello?name=sparrow' > modules/hello/story.bash
$ echo 'hello sparrow' > modules/hello/story.check


# GET /bye
$ echo '$project_root_dir/app.pl get /bye?name=sparrow' > modules/bye/story.bash
$ echo 'bye sparrow' > modules/bye/story.check

And main story-container to call them all:

$ echo 'Smoke tests for app.pl' > meta.txt
$ nano hook.bash

run_story welcome-page
run_story hello
run_story bye


$ strun

/ started

Smoke tests for app.pl

/modules/welcome-page/ started

[Sun Dec 11 19:34:08 2016] [debug] GET "/"
[Sun Dec 11 19:34:08 2016] [debug] Routing to a callback
[Sun Dec 11 19:34:08 2016] [debug] 200 OK (0.00091s, 1098.901/s)
welcome page
ok      scenario succeeded
ok      output match 'welcome page'

/modules/hello/ started

[Sun Dec 11 19:34:09 2016] [debug] GET "/hello"
[Sun Dec 11 19:34:09 2016] [debug] Routing to a callback
[Sun Dec 11 19:34:09 2016] [debug] 200 OK (0.000871s, 1148.106/s)
hello sparrow
ok      scenario succeeded
ok      output match 'hello sparrow'

/modules/bye/ started

[Sun Dec 11 19:34:09 2016] [debug] GET "/bye"
[Sun Dec 11 19:34:09 2016] [debug] Routing to a callback
[Sun Dec 11 19:34:09 2016] [debug] 200 OK (0.001051s, 951.475/s)
bye sparrow
ok      scenario succeeded
ok      output match 'bye sparrow'
STATUS  SUCCEED

What we have done here.

• created 3 story modules each for a route (GET /, GET /hello , GET /bye )
• create a story-container to call a story modules
• run strun to execute test suite

More about story modules and story containers be found at Outthentic - a module for execution sparrow scripts.

Parameterizing test suite

We hardcoded a string sparrow get passed as parameter to routes GET /hello and GET /buy. Let's parametrize out test suite:

$ nano modules/hello/story.bash

name=$(story_var name)
$project_root_dir/app.pl get '/hello?name='$name


$ nano hook.bash

run_story welcome-page
run_story hello name Mojolicious
run_story bye

And then run our test suite:

# some output truncated ...

/modules/hello/ started

[Mon Dec 12 12:42:04 2016] [debug] GET "/hello"
[Mon Dec 12 12:42:04 2016] [debug] Routing to a callback
[Mon Dec 12 12:42:04 2016] [debug] 200 OK (0.000845s, 1183.432/s)
hello Mojolicious
ok      scenario succeeded
not ok  output match 'hello sparrow'

/modules/bye/ started

Obviously our test failed as we need to change a check list:

$ nano modules/hello/story.check

generator: [ "hello ".(story_var('name')) ]

Generators are way to create story check list in runtime. More on this read at Outthentic doc pages.

story_var is bash helper function letting our stories to get the parameter they are called from story container. By the way as sparrow is kind language agnostic framework we could write our code on plain Perl:

$ nano modules/hello/story.pl

my $name =  story_var('name');

my $cmd = project_root_dir()."/app.pl get '/hello?name=$name'";

print `$cmd`

Or even Ruby:

$ nano modules/hello/story.rb

name =  story_var 'name' 

puts `#{project_root_dir}/app.pl get '/hello?name=#{name}'`

I did not tell you, one day I am going to add Python support ... :)

Ok, now let's make our name parameter configurable via configuration file

Configuring test suites

Sparrow test suites maintain three well known configuration formats:

• Config::General ( probably most convenient way to describe various configurations )
• JSON
• YAML

Let's go with Config::General. As our example quite trivial the configuration won't be too complicated:

$ nano suite suite.ini

name Sparrow


$ nano hook.bash

name=$(config name)
run_story welcome-page
run_story hello name $name
run_story bye name $name

We can even use nested configuration parameters:

$ nano suite suite.ini

<name>
  bird Sparrow
  animal Fox
</name>


$ nano hook.bash

bird_name=$(config name.bird)
animal_name=$(config name.animal)

run_story welcome-page
run_story hello name $bird_name
run_story bye name $animal_name

And finally we can override parameters via command line:

$ strun --param name.animal='Bear'

As I said we could use another configuration formats, like for example JSON:

$ nano suite.json

{

  "name" : {
    "bird"    : "sparrow",
    "animal"  : "bear"
  }
}


$ strun --json suite.json

Processing output data

Sometimes we need to process output data to make it testable via Sparrow. It's very common when dealing with application emitting JSON:

$ cat app.pl

#!/usr/bin/env perl

use Mojolicious::Lite;

get '/echo-name' => sub {
  my $c = shift;
  $c->render( json => { name => $c->param('name') } )

};

app->start;

Sparrow does not provide any built in capabilities to parse JSON, but it rather acts as tool where one can add any desired modules into "pipeline":

$ nano hook.bash

name=$(config name)

run_story echo-name name $name

$ mkdir -p modules/name

$ nano modules/echo-name/story.bash

name=$(story_var name)

$project_root_dir/app.pl get '/echo-name?name='$name \
| perl -MJSON -e 'print decode_json(join "", <STDIN>)->{name}'

Now let's run the test:

/ started

Smoke tests for app.pl

/modules/echo-name/ started

[Tue Dec 13 12:00:18 2016] [debug] GET "/echo-name"
[Tue Dec 13 12:00:18 2016] [debug] Routing to a callback
[Tue Dec 13 12:00:18 2016] [debug] 200 OK (0.00054s, 1851.852/s)
sparrow
ok  scenario succeeded
ok  output match 'sparrow'
STATUS  SUCCEED

This approach could be generalized to any data processing like YMAL/XML/CSS. Instead of defining data parsing at test logic we filter/process output data to "map" it to sparrow testing format - just a lines of text where we could make regexp/text search.

Ok let's keep moving. Prepare our test suite for distribution.

Distributing tests

A one thing we should pay attention to. A mojolicious application we write tests for in practice is distributed separately from sparrow test suite. There are some cases:

• an application gets installed and launched as script available at system $PATH
• an application gets tested via some CI pipelines, for example Travis

Whatever case we consider it's not hard to adopt our test suite to new reality. For example if there is script called our_mojolicious_application we just need to change small bit of code to rely on system wide installation instead of local:

$ nano modules/hello/story.bash

name=$(story_var name)

our_mojolicious_application get '/hello?name='$name

That is it.

Declaring dependencies

Sparrow works smoothly with Perl/Ruby well known dependency managers to work out on this, just create a cpanfile with dependencies in case of Perl:

$ nano cpanfile

requires 'JSON'; # indeed not required for recent Perls

Providing test suite meta information

This is important point where we define some data to make it possible upload our test suite to SparrowHub - a sparrow scripts repository

$ nano sparrow.json

{
    "name"            : "mojolicious-app-smoke"
    "description"     : "smoke tests for our Mojolicious application",
    "version"         : "0.0.1",
    "url"             : "https://github.com/melezhik/mojolicious-app-smoke"
}

We name our test suite, give it a version, provide short description and provide source code link (github).

Also let's provide a small README.md to let other understand what it is:

$ nano README.md

# SYNOPSIS

Make some smoke tests against our mojolicious application

# INSTALL

$ sparrow plg install mojolicious-app-smoke

# USAGE

$ sparrow plg run mojolicious-app-smoke

# Author

Alexey Melezhik

Now let's commit our changes

$ git init
$ git add .
$ git commit -a 'first commit'
$ git remote add origin https://github.com/melezhik/mojolicious-app-smoke.git
$ git push -u origin master

Finlay we are ready to upload a test suite to SparrowHub:

$ sparrow plg upload

sparrow.json file validated ... 
plugin mojolicious-app-smoke version 0.000001 upload OK

Once you make changes to your test suite you bump a version and release a new stuff into Sparrowhub. As I told you a sparrow test suite has it own life cycle separated from application being tested.

Finally If for security reasons you don't want to make your test suite public Sparrow allow you to host your scripts at private git repositories ( github/bitbuket).

Get it run

Ok. Now having a test suite as sparrow plugin we could easily install and run it somewhere we need:

$ sparrow plg install mojolicious-app-smoke
$ sparrow plg run mojolicious-app-smoke

We can even override a test suite parameter via command line:

$ sparrow plg run mojolicious-app-smoke --param name.bird=woodpecker

Or create a configuration via sparrow task:

$ sparrow project create webapp
$ sparrow task add webapp smoke-test mojolicious-app-smoke
$ sparrow task ini webapp/smoke-test

<name>
  bird Woodpecker
  animal Fox
</name>

To get plugin documentation simply run:

$ sparrow plg man mojolicious-app-smoke

Or view plugin page at SparrowHub site - https://sparrowhub.org/info/mojolicious-app-smoke .

There are many other fun things you could do with Sparrow API, please follow Sparrow documentation.

Summary

What we have just learned:

• How the sparrow approach differs from classic unit tests for Perl
• How to create sparrow scenarios to test Mojolicious applications
• How to distribute sparrow tests suites with the notion of so called sparrow plugins

Regards

Alexey Melezhik

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

Not long time ago I asked a community about possible service to run integration tests for existed cpan modules , not having too much feedback I decided to run such a service to make my suggestion visible and available to try for other users.

So, meet CPANParty - an alternative integration tests for cpan modules. Right now service is hosted on swatpm site, but in the future I will probably move it to dedicated domain.

Only a few randomly chosen cpan modules was picked up and tested. Eventually I will add more.

So, questions, ideas, issues?

Please comment here or to https://github.com/melezhik/cpanparty

Thanks in advance

Alexey Melezhik

PS CPANParty reports page below

No, this is not about holy war ! I do respect other tools (-: , really

But rambling on stackoverflow I found quite interesting question about web tests automation. The author started using curl for quite simple test automation task and then changed to selenium web driver, the reason was quite obvious - curl has request oriented design which make it hard to use it when making complicated, sequential requests in a whole test story.

But curl is still cool stuff to get rid of , but you don't have to ... if you use swat PLUS curl.

So here is my answer ...

Hi!

I have just released swat, version 0.1.80 to support JSON/XML applications testing with the help of so called response processors.

Regards

-- Alexey

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!

Hi! This is sparrow / swat related article http://habrahabr.ru/post/272245/ written on Russian language.

Hi, this is very simple and short example, but quite expository.

install sparrow

$ sudo apt-get install curl
$ sudo cpanm Sparrow

installs nginx sparrow plugin

$ sparrow index update
$ sparrow plg install swat-nginx

setup monitored host

$ sparrow project foo create
$ sparrow check add foo nginx-server
$ sparrow check set foo nginx-server -p swat-nginx -u 127.0.0.1

and finally ... run test suite

    $ sparrow check run foo nginx-server

    # sparrow environment initialzed at /home/vagrant/sparrow
    /home/vagrant/.swat/.cache/20277/prove/00.GET.t ..
    ok 1 - GET 127.0.0.1/ succeeded
    # response saved to /home/vagrant/.swat/.cache/20277/prove/jgxseRgqg2
    ok 2 - output match '200 OK'
    ok 3 - output match /Server: nginx\/(\S+)/
    ok 4 - valid nginx version: 1.6.2
    1..4
    ok
    All tests successful.
    Files=1, Tests=4,  0 wallclock secs ( 0.03 usr  0.00 sys +  0.05 cusr  0.00 csys =   0.08 CPU)
    Result: PASS

PS

Visit https://github.com/melezhik/sparrow to know more.

Tiny but quick sparrow

Let me introduce you a sparrow - a tiny web monitoring / test tool . Tiny as project is in very alpha stage, but I hope it will grow and get mature and get used by others.

Sparrow is a console client to setup tests/monitoring infrastructure and run swat tests suites. Swat - is web test application automation framework. Sparrow provides some glue to run sparrow plugins - shareable swat tests suites.

Here is the list of some sparrow plugins created by me - https://github.com/melezhik/sparrow-hub

Swat was initially designed to radically increase and simplify web tests development. Another idea behind swat philosophy - is to create shareable tests suites could be reused by someone else with different context ( monitoring, QA, development, devops ) but in easy manner.

Recently I have posted a informal swat introduction paper with the list of swat test suites could be base for such a sparrow plugins.

If you are inspired in test automation development on perl we probably could go one direction. So swat/sparrow contributors are needed!

Possible impact:

• start using swat,sparrow and sparrow plugins
• create new sparrow plugins ( swat test suites ) - it's really easy
• contribute to sparrow - there is some TODOs here - implementing REST API, clear up documentation and my documentations typos, (--; , etc
• contribute to swat - the api is going to be stable, but I am open to new ideas as Russians say two heads are better then one (-;

--- Thanks, Alexey Melezhik ( the author of swat and sparrow )

Hi! I am very glad to announce of outthentic stuff latest releases:

• Outthentic::DSL - a core component for all outthentic test clients
• Outthentic client - a general purposes test tool ( based on Outthentic::DSL )
• Swat client - a web application test tool ( based on Outthentic::DSL )

So. Follow metacpan/github docs, find your proper tool and enjoy your testing with Outthentic!

Site has become quite concise but has interesting info about swat:

• fork me on github button :) - this one is classic
• 1 minute tutorial on swat tests
• list of projects using swat ( more ones are wanted! :) )
• list of swat examples

Hi!

I have just started a repository of portable web tests - http://swatpm.org
This is an alpha stage. Please follow up:

- Read what swat is
- Create your test suite useful for others
- Publish it to CPAN
- List it to http://swatpm.org

---

Regards. Alexey.