Testing approach and quality expectations

[EyalLavi]

Things we might want to consider:

• BDD, unit tests?
• Code review standards
• Python style (PEP8?)
• Code quality tooling (statistical analysis, style)

For discussion.

[MikeSmithEU]

As well as (auto) documentation (I've added a sphinx setup to #13). In that pull request only some basic doctesting is done.

[MikeSmithEU]

Basic autogenerated documentation viewable at https://conferatur.mikesmith.eu

[MikeSmithEU]

My input on the questions:

• BDD, unit tests?
  I'm all for BDD, but have not yet done it yet. We might need someone with some experience here to step forward to guide us through the proper workflows and to choose the proper Python modules to use here.
  Unit tests are a must, in Python I've mostly (mis)used doctests, again if someone can suggest their favourite flavour of testing framework I'm all for it.
• Code review standards
  These are mostly dependent on the other decisions, mostly I will try to safeguard spelling, the decided standards, enforcing KISS, avoiding code duplication and bad practises (eg. unnecessary nested loops, solving things with nested if's and elif's that include too much unnecessary complexity when it can be "structurally/abstractly" solved, etc.). But of course someone should guard the guardian as well ;)
• Python style
  PEP8 is pretty much a must-have for me. Bear in mind this allows for exceptions to this standard when advisable: "A Foolish Consistency is the Hobgoblin of Little Minds"
  PEP20 is also a good guideline to keep in mind...
• Code quality tooling (statistical analysis, style)
  We should look to have continuous integration, I suggest using Travis CI, other flavours are available and am very much open to suggestion.

Much of these questions relate to one another. A number of decisions need to be made before being able to actually implement these.

1. Code structure
2. Use PEP8?
3. Which testing/BDD framework will we use?
4. Which CI will we use?

[MikeSmithEU]

Basing this off of #19

For now these decisions have been made and done (but none are binding):

• code structure is widely accepted python standard (src/ folder containing modules, a setup.py, docs/ folder for autogenerated documentation via sphinx etc.)
• PEP8: YES (the one thing that for me shouldn't be up for discussion)
• Testing via py.test (we might want to do some BDD now the basic setup of the project is done, looking for feedback here)
• Current CI done by TravisCI ( https://travis-ci.com/MikeSmithEU/ai-benchmarking-stt ) We should register an account for EBU (does it exist already?) so we can start the CI for the main origin instead of my fork
• Auto documentation generation via sphinx (comments in rst format with :param type name: description etc, is widely used, no true adopted standard way of doing this in python
• Am using PyCharm myself as editor (free!, PEP8 hints, vim edit mode, etc)
• Frontend stuff (api json explorer) should mostly be limited, the exposed api should enable custom frontends anyway. Using Flask with gunicorn as WSGI HTTP Server to be production-ready
• For frontend, currently no static files are being served, once this is needed, we should add nginx into the mix
• Automatic adding of new normalisers to json api calls and command line tools, documentation and examples provided via docblocks (the grunt work for this is done)
• own csv/configfile parser written and debugged

What needs to be decided, looking for feedback and volunteers to implement:

• Code coverage reports and goals
• BDD ? Which framework?
• Code reviewers: will obviously take this on myself to a big extent, need other experienced developers to volunteer for this as well

[MikeSmithEU]

Replaced by #21 #22 #23 and #36