[liblouis-liblouisxml] Re: [liblouis] r642 committed - Added version2 of runHarness, based on nose tests....

  • From: Michael Whapples <mwhapples@xxxxxxx>
  • To: liblouis-liblouisxml@xxxxxxxxxxxxx
  • Date: Tue, 29 May 2012 13:43:54 +0100

Firstly on test types, f/b I guess would be OK, however I probably would have 
gone with the actual function name (eg. translate/backtranslate/hyphenate) so 
that as functions are added to liblouis its obvious what the value might be in 
the test file.

As for showing the typeform information, one option might be to have a string 
with letters representing the typeform. I think the following would work for a 
string (no commas between letters):
[typeformMap[x] for x in typeform]
Where typeformMap is a dictionary mapping the letters to the typeform int 
values. See how I mapped modes for the type of dictionary.

I think the above would be compact while the letters (eg. I for italics, B for 
bold, etc) would be intuitive. We could use an int list in JSON, however I 
would not like using ints in the data file incase the values get changed in 
liblouis, we should try and use the constants where possible.

As for doctests or creating a unit test function, I would probably prefer the 
doctest if possible as it has little other stuff and so makes it a clear code 
usage example with no extra test code showing. Also, I think even creating a 
test like you describe may still suffer with python2 and python3 issues, or if 
not then would possibly be difficult to read for anything using unicode 
characters not in ASCII. I guess in short, if it would be acceptable to support 
only one python version then doctest would win for me, however if supporting 
both then the things I like with doctests would be lost anyway.

Michael Whapples
On 29 May 2012, at 13:08, Mesar Hameed wrote:

> Hi,
> On Tue 29/05/12,12:54, Michael Whapples wrote:
> 
>> As for extending the JSON test files for other cases, I have some ideas. It 
>> mainly revolves around an idea that a "type" field could be given 
>> to specify what type of test is to be performed (if type is not given then 
>> the standard translate test is assumed), and then one gives 
>> relevant fields for that test type, some fields may be required others might 
>> be optional. This should mean that all test types would be 
>> fairly compact.
> 
> Agree, Attila and I are already working on this, although personally I will 
> not have much time before the weekend.
> new fields so far:
> 'comment': a n optional comment field to describe the purpose of the test.
> 'direction': [f/b] forward/backward translation, if omitted assumes forward.
> 
> The more tricky one is how to do we want to represent mask information, 
> compactly, for tests for bold/italic etc.
> 
>> I still see advantages to the doctest system as it provides examples and can 
>> run any type of code, however it seems harder to support python2 
>> and python3 in a single file for them.
> 
> If we need more flexibility, that the standard harness doesnt give, the test 
> writer can always write test_xxx which can test any functionality 
> that may be required. They are fully valid python functions.
> This should also be still more cross compatible with p2/p3 than the doctests.
> 
> How do you feel about this?
> 
> Mesar
> For a description of the software, to download it and links to
> project pages go to http://www.abilitiessoft.com

For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com

Other related posts:

  1. Home
  2. liblouis-liblouisxml
  3. Archive
  4. 05-2012