This week was more relaxed and fun, since my mentors,
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
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
#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
.tfile should correspond to a
.tfile 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
As an example of one of my tests. Here is
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', );
For week #3, the following are the key points:
- 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.