Sunday, July 18, 2010

Interim Report

All of the tests for BioRuby classes in bio/, bio/db/ and bio/lib/ are executed correctly, Covering about 90% of total lines.
Although Ruby 1.8.7 outputs some warning, They pass all the tests.
I have skipped other classes in bio/appl/ and bio/io, because of dependency on external library or web services.
I haven't worked on the tests for the classes in bio/shell/, since I don't understand how they are composed.

A test in bio/, bio/db/ and bio/sequence/ with Ruby 1.9.2 says that BioRuby has some errors about Compatibility of Float, String and methods.
However, almost the classes pass the tests.

Saturday, June 26, 2010

Bio::MEDLINE

There is a unit test for Bio::MEDLINE.
I replaced it into new one.
New Bio::TestMEDLINE tests all of the methods in Bio::MEDLINE and use the same sample file.
It has 100% coverage to Bio::MEDLINE.

Sunday, June 20, 2010

Bio::KEGG

There are 5 files witch don't have the files for unit test.

I skipped Bio::KEGG::Brite, It probably has the same methods as KEGGDB.

Bio::TestBioKEGGEXPRESSION outputs the following result now.
12 tests, 7 assertions, 6 failures, 5 errors
I checked the following error of them.
4) Error:
test_down_regulated(Bio::TestBioKEGGEXPRESSION):
Errno::EDOM: Numerical argument out of domain - log10
    ./lib/bio/db/kegg/expression.rb:128:in `log10'
    ./lib/bio/db/kegg/expression.rb:128:in `logy_minus_logx'
    ./lib/bio/db/kegg/expression.rb:127:in `each'
    ./lib/bio/db/kegg/expression.rb:127:in `logy_minus_logx'
    ./lib/bio/db/kegg/expression.rb:99:in `down_regulated'
    test/unit/bio/db/kegg/test_expression.rb:77:in `test_down_regulated'
The reason is that test_down_regulated gives a negative value to Math.log10.

I skipped Bio::KEGG::KGML because it is just a wrapper class of REXML.

I haven't written Bio::KEGG::Common, Bio::KEGG::KEGGTAB and Bio::KEGG::Taxonomy (the latter two classes may not be so important.).

Bio::GO

Bio::TestGo class tests almost all code in Bio::GO, Bio::GO::GeneAssociation and Bio::GO::External2GO.
It doesn't cover part of dag_edit_format_parser(str).
In addition, It outputs an error in "to_str" method of Bio::GO::GeneAssociation class, because the method doesn't assume empty value in each instance variable.

Bio::Sequence


Bio::Sequence::Format::Formatter
I made fake class witch has only a simple output method to test FormatterBase. The unit test class has the test for output method with the fake class.

Bio::Sequence::Adapter
It has a clss for a data source class connected by the adapter and a class witch is the interface. In addition, it has adapter class witch extends an adapter module. It tests Bio::Sequence::Adapter through the interface class.

Bio::SQL

It has two kinds of unit test.
TestBiosqlIO class in ts_biosql.rb connects and accesses MySQL, so It can tests a execution environment to test whether Bio::SQL works.
tc_biosql.rb has only a require statement of 'tc_biosql', I'm not understand how to use it.
Does it need to test only the logics of the methods in Bio::SQL with the fake class of the database.?

Bio::GenBank

Bio::NCBIDB::Common
It is tested in Bio::NCBIDB::TestCommon. Bio::NCBIDBCommon class includes Bio::NCBIDB::Common. Instead of Bio::NCBIDB::Common, It is used in the unit test. This class has low coverage, because a sample entry used in it lacks a lot of fields. There are all the methods except for "locus" method,which is override in the child class.

Bio::GenBank
its unit test tests the methods in Bio::GenBank, including the methods returning Bio::GenBank::Locus and Bio::Feature objects Should the sample file be simpler than now?

Bio::GenPept
The coverage of this class is 100% It tests only the methods descripbed in the soruce class.(It dosen't test the inherited met hods from NCBIDB)

Bio::DDBJ
I didn't write the unit test, since it has the same methods as Bio::GenBank.
Bio::RefSeq
I didn't write the unit test, since it has the same methods as Bio::GenBank.

Wednesday, June 16, 2010

shift to Characterization test

  • I have to make the unit test for the classes someone made.
  • I have been studying the classes and making the unit tests for them simultaneously.
  • Some class files have the examples of use in the comment statements
This is why I will start to make the tests with Characterization test until now.
Basically, I will prepare a test class for a class, and test the behaviors for the methods.
I won't write tests for private methods. I will write them only for methods that can be accessed externally.
However, even if they are private methods, they should pass C0 test.(I will manage it with rcov.)

Monday, June 14, 2010

design criteria for Unit Test

  • Prepare unit tests for each class.
  • For each module, prepare the mock classes that include each the module
  • When a class is prepared only for internal use or tightly-coupled with another class, I won't prepare the unit test for the class, but prepare it for the central class.

What I did in the second week.

There are some classes which don't have unit tests in the following directories.
appl/
compat/
db/
io/
sequence/
shell/
util/
I'm making unit tests for the classes in db/, such as Bio::PDB::*, Bio::GenBank::*, Bio::KEGG::*.
I'd like to create the unit test completely in the directory within this week.

Sunday, May 30, 2010

start making the unit tests

As I say in my proposal, I started creating the unit tests for BioRuby.
In BioRuby library, 142 files don't have the unit test files.
I will create the unit test for the files that don't use external libraries or softwares in them by next Sunday.
Currently I create unit tests for the files in db directry (I know I'm late..).

Monday, May 24, 2010

rcov and heckle

rcov checks line coverages.
Heckle is a mutation tester.

Thursday, May 20, 2010

What I have to survey

Ruby
Difference between 1.8.7 and 1.9.2. How to overcome the difference
BioRuby
classification of the methods in terms of dependency on other libraries
The way of the test
The way of writing the unit tests. leaning what behavior I have to check and how do I check them

Tuesday, May 18, 2010

How to detect classes not having the unit tests.

Only part of class files have the equivalent test files In BioRuby.
In order to see a whole coverage of the unit test to the all class files with rcov, I have to develop the empty test files for the class files not having them.
The process is as follows.

First, make sure which files in the lib directory don't have the equivalent test files


Seconde, prepare each test file in witch the equivalent lib file is required.

Third, execute rcov to visualize the whole coverage


Sunday, May 16, 2010

About Code Coverage

This page says that "Code Coverage" is divided into the three phases, C0, C1 and C2.
The following are the summaries of the three phases to one program.

C0 is How many lines the test code checked.
C1 is what percentage of the conditional statements the test code checked.
C2 is whether the test code checked all the likelihood of the procedures.

In the case of Ruby, you can visually check C0 with rcov.

Saturday, May 15, 2010

How many tests dose BioRuby have?

Bioruby has 235 files in the lib directory and 108 files for the test.
Result from a investigation, the 133 files in the lib directory don't have the test files which are the same names as them.
On the other hand, the 102 files in the lib directory have the test files.
As for the 6 test files, it is unclear which files they match.
(There are 9 .rhtml files in the BioRuby, which don't have the files for the unit tests.)

Tuesday, May 4, 2010

Tips to keep compatibility between various versions

For the purpose of maintaing compatibility between Ruby 1.8 and Ruby 1.9, "Ruby Best Practices" suggests better ways as follows.
write codo against Ruby 1.9 first and then backport to 1.8

In order to avoid writing too much legacy code, we seem to have to write code supporting the later version first. It cannot apply to my project because BioRuby has already support the earlier version.

attempt to find a way to write code that runs natively n both Ruby 1.8 and 1.9

Avoid implementing redundant code or modifying core Ruby code as much as possible

consider backporting the necessary functionality to Ruby 1.8

If a method used in the library is different between Ruby 1.8 and 1.9, you should create new methods in classes of one version for the compatibility.

Introduce a helper method that behaves the same on both versions

For example, you may add Enumerator to String of Ruby 1.8. That provide the same behavior as "lines" method of Ruby 1.9

use brocks for the version checking

Don't use a conditional statement. Use the following code
def hoge(bar)
ruby_18 {...} || ruby_19 {...}
end
this way centralizes incompatibility.

reference: Brown G. Ruby Best Practices. O'Reilly Media, Inc. 239-249; 2009.