Skip to content

Data Driven Testing #117

@janmotl

Description

@janmotl

I was thinking about applying data driven testing (ddt).

Why ddt:

  1. test_encoders contains a lot of copy-pasted code
  2. test_estimators already loops over all encoders
  3. ddt, in comparison to a simple loop, does not stop on the first error (unless you tell it to do so) and reports results for each subtest (not just for the whole loop)
  4. ddt makes it easy to quickly increase test coverage
  5. ddt makes it easy to test that all encoders in the library fulfill some basic requirements

But of course, there are disadvantages:

  1. It makes it slightly harder to understand and write tests
  2. I have encountered behaviors (two, to be exact) that could be considered valid but break uniform behaviour of the library. I do not know what to do - adjust the tests or the encoders?

Example of the code.

Questions:

  1. Should I continue in the effort to port portable tests under ddt while preserving the encoder specific tests?
  2. If yes, is it ok to make a branch instead of a pull request? I hope it is going to be easier (for me) to maintain synchronicity between the development and master branch.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions