* Algorithm
** Code organisation
   The algorithm follows roughly those steps:
   1. The germlines are read. germlines are in the fasta format and are read
      by the Fasta class (=core/fasta.h=). Germlines are built using the
      Germline (or MultiGermline) class (=core/germline.h=)
   2. The input sequence file (.fasta, .fastq, .gz) is read by an OnlineFasta
      (=core/fasta.h=). The difference with the Fasta class being that all the
      data is not stored in memory but the file is read online, storing only
      the current entry.
   3. Windows must be extracted from the read, which is done by the
      WindowExtractor class (=core/windowExtractor.h=). This class has an
      =extract= method which returns a WindowsStorage object
      (=core/windows.h=) in which windows are stored.
   4. To save space consumption, all the reads linked to a given window are
      not stored. Only the longer ones are kept. The BinReadStorage class is
      used for that purpose (=core/read_storage.h=).
   5. In the WindowStorage, we now have the information on the clusters and on
      the abundance of each cluster. However we lack a sequence representative
      of the cluster. For that purpose the class provides a
      =getRepresentativeComputer= method that provides a
      KmerRepresentativeComputer (=core/representative.h=). This class can
      compute a representative sequence using the (long) reads that were
      stored for a given window.
   6. The representative can then be segmented to determine what V, D and J
      genes are at play. This is done by the FineSegmenter (=core/segment.h=).
* Tests
** Algorithm
*** Unit
    Unit tests are managed using an internal lightweight poorly-designed
    library that outputs a TAP file. They are organised in the directory
    [[../algo/tests][algo/tests]].

    All the tests are defined in the [[../algo/tests/tests.cpp][tests.cpp]] file. But, for the sake of
    clarity, this file includes other =cpp= files that incorporates all the
    tests. A call to =make= compiles and launched the =tests.cpp= file, which
    outputs a TAP file (in case of total success) and creates a =tests.cpp.tap=
    file (in every case).
**** Tap test library
     The library is defined in the [[../algo/tests/testing.h][testing.h]] file.

     Tests must be declared in the [[../algo/tests/tests.h][tests.h]] file:
     1. Define a new macro (in the enum) corresponding to the test name
     2. In =declare_tests()= use =RECORD_TAP_TEST= to associate the macro with a
        description (that will be displayed in the TAP output file).

     Then testing can be done using the =TAP_TEST= macro. The macro takes three
     arguments. The first one is a boolean that is supposed to be true, the
     second is the test name (using the macro defined in =tests.h=) and the
     third one (which can be an empty string) is something which is displayed
     when the test fails.


** Browser
*** Functional
    All the browser functional testing is done in the directory
    =browser/tests=.
    
    Several stuff must be installed to launch the functional browser
    tests. Please see the doc in browser-tests.org.

    The functional tests are built using two base files:
    - vidjil_browser.rb :: abstracts the vidjil browser (avoid using IDs or
         class names that could change in the test). The tests must rely as
         much as possible on vidjil_browser. If access to some
         data/input/menus are missing they must be addded there.
    - browser_test.rb :: prepares the environment for the tests. Each test
         file will extend this class (as can be seen in test_multilocus.rb)

    The tests are in the files whose name matches the pattern =test*.rb=. The
    tests are launched by the script in =launch_functional_tests= which launch
    all the files matching the previous pattern. It also backs up the test
    reports as =ci_reporter= removes them before each file is run.