byterock

So today in the Moose-pen I am not going to any coding just another of those little planning review sessions one should take when creating a new system.

So for the two-bit review,

• Planned out and amended my basic API
• Settled on the basic architecture
• Done some PoC programming
• Now know where som of the problem area will be.
• Have some workable tests

So my next step was to migrate all my code out from the blog repository up on git-hub and into its own git-hub repository which I have done. I also want to set this up the same way I would do a Perl distribution so I stubbed in some of the necessary files namely a README, a Makefile.PL and the GNU license.

Next I had a close look at the present state of the code. I only moved over the code directly related to Database::Accessor name-space, at this point is just the Accessor.pm file and its embedded classes.

I did not bring over anything under the Database::Accessor::DAD name-space as these will be coming out as seperate perl distributions. I noticed that I had a Role name-space under Database::Accessor and I was thinking of getting rid that as well but I will leave it in for now as I have not done any re-factoring for roles at this point.

Now for the meat of today's post the 't' folder. I moved over all the pertinent tests and renamed a few but I what I have to do is come up with a better test plan than what I have now.

The first point is that Database::Accessor itself does not really 'do' anything. It does not manipulate or interact with any Data Base it only provides data in the form of classes both static and dynamic to a DAD, (Data Accessor Driver) that then uses that to manipulate or interact with a Data Base.

So for Accessor testing I have to strip out all the DAD related testing I have present and concentrate on what I am promising to supply the DAD is correct.

At one point I was thinking testing all the attributes of the various Database::Accessor classes. As I am using Moose I do not have to test to see if a value is of a certain type or if the setter or getter works, it is just a given so lots of time saved there.

So for my test plan I see the following naming pattern;

00~09 basic sanity tests
10~19 Database::Accessor Classes sanity test
20~29 DAD load tests
30~39 Accessor.pm static tests
40~49 Accessor.pm dynamic tests
50~69 Integration.

In the 10~19 test cases I will be adding tests for each of the embedded classes in Accessor.pm. So each time I add a new Class in Accessor.pm I will add a test here, thus ensuring that catch any mistakes early.

In the 20~29 range I will be adding test to ensure that my Accessor.pm can properly load in a DAD.

So once these have passed I can move to my 30~49 range which will be testing the static attributes of Accessor.pm ensuring the the correct type can be passed in and the coercion is working correclty. The 40~49 range will be the same except it will be for any dynamic attributes.

Now in these two test ranges I will be doing my coercion tests along with basic loading into the Accorrop.pm. I have always found that spliting coercion into a number of tests cases is good pratice because if you a test too big, it can be very hard to debug.

The 50~69 range is for integration testing the DAD. These tests will be checking that all the promised parts from my DAD role are present and that the data has been properly passed into the DAD for use.

That is about it now onto work.