Status Report for Week #2 in gnusosa

Status Report for Week #2

This week was more relaxed and fun, since my mentors, sawyer & franck, helped in the process of reviewing my commits and every bad code snippet that I unintentionally commit. As well, it was a week when I decided to take on other activities, and get off the grid for a while. To disconnect helps to review all the most random ideas and actions of your day. This is included in the student guidelines of the GSoC as a good practice. So just like sawyer told me, relax. That’s the lesson of this week for me.

What I worked on week #2

I finished the OO module of the creation of a Dancer app. I finally finished successfully moving the old script intact to an object oriented module. Yes, just like the project schedule suggests, the module is done, for now. So now more of a rough draft, it’s an actual working OO module, that writes, modifies, and asks about writing on top of existing dirs/files on the current path. As it was expect from the old script the module does verbose the help POD and the version of the local installed Dancer setup, and keeps track of the most current Dancer version on CPAN.

After that, I started working on the tests. This was my real challenge, but not so much on the side of the technical detail of the methods from Test::More, and what is expect from each testing method. The real work for me, was the dealt of time you invest thinking about what to test. So I wrote tests for the new method which declares the class and returns itself. Inside of that method, you can find _set_* methods that establish the working global variables of the module. I added tests to those, and several other methods which returned lists and objects. Along to that, I added string tests for this returned list, and other tests for text.

What I learned in the week #2?

Well pretty much everything was related to tests, and basically, it comes down to when to or what to implement a test to. So what to test? Basically:

Anything that can return a condition in binary.
Anything that is an object.
Anything that is identified by a keyword or string.
Anything that access a file, read or write.
Anything that returns a scalar that can be compared.

I used the standard module for any unit-test in Perl, Test::More. For my tests I only used the following from Test::More:

#define the tests
use Test::More tests => n;

use_ok( 'Some::Module' ); #it loads?

#for definitions, scalars and strings comparisons.
ok($got eq $expected, $test_name);

is  ($got, $expected, $test_name);
isnt($got, $expected, $test_name);

#for object, and classes testing.
can_ok($module, @methods);
isa_ok($object, $class);

Most of the tests I wrote were thought on the functionality of the module. That’s why I didn’t use Dancer::Test which is great for testing a functional Dancer app, but not for the module that creates the app. Following that guideline, I find that testing something you don’t use is not quite common. It is always noted to be done on an specific issue. So I took this as the real guideline of all I did, and is something I took from Modern Perl:

Each .t file should correspond to a .pm file.
Each .t file should correspond to a feature.

So what you get from the last, a pretty solid guideline for your test organization, and after you’ve done all that work you can merge every .t file into one big file, for example 01-basic.t in common CPAN modules.

As an example of one of my tests. Here is new.t:

use strict;
use warnings;
use Test::More tests => 4;
use Dancer::Script;

use_ok( 'Dancer::Script' );

my $script = Dancer::Script->new(
appname => 'Hello', path => '.', check_version => '1');

isa_ok( $script, 'Dancer::Script', );
can_ok( $script, 'parse_opts',
 'validate_app_name', );
can_ok( $script, '_set_application_path',
'_set_script_path', '_set_lib_path', );

What’s next?

For week #3, the following are the key points:

Study Catalyst scripts and Catalyst::ScriptRunner.
Derive a code from both to merge to the project.

The first point won’t be that hard, since I took the time to study both Script modules, and work on something that might work, at least model wise. It will depend on what my mentors think is best for the project. On the second point, I find it a bit difficult, but since Dancer::Script is fully working, it might help as a reference to compare with Catalyst scripts.

On another note, everybody seemed to be relaxing for the weekend, or working on another stuff that was not related to GSoC. I guess everybody needs some time off the grid. Will see how this works in week #3 for all the mentors and the students. Let’s hope that everybody can have some time for their own work and activities.

Carlos Sosa