Best strategy for testing class and subclasses in pytest?

[C.D. Reimer]

Greetings,

I'm writing a chess engine to learn about Python classes and
inheritance, and using pytest for the unit test. I've created a Piece
class, which has 99% of the functionality for a chess piece, and
subclass the other pieces -- Bishop, King, Knight, Pawn, Queen, Rook --
that will implement the move-specific functionality. I'm not sure what's
the best strategy is for testing the class and subclasses.

I initially wrote unit tests for the class and subclasses (including
tests for class-only functionality). That worked well until I started
refactoring code and breaking the tests. Too much copy, paste and
renaming for my taste.

I tried to create a separate class and/or module to import the common
tests for each class and subclass. My attempts often ended in failure
with the "RuntimeError: super(): no arguments" message. I couldn't find
a working example on the Internet on how to do that. The pytest
documentation is all over the place.

Is there a way to reuse tests in pytest?

Or should I test everything in the class and test only the implemented
functionality in the subclasses?

Thank you,

Chris R.

[dieter]

"C.D. Reimer" <ch...@cdreimer.com> writes:

> I'm writing a chess engine to learn about Python classes and inheritance, and using pytest for the unit test. I've created a Piece class, which has 99% of the functionality for a chess piece, and subclass the other pieces -- Bishop, King, Knight, Pawn, Queen, Rook --
> that will implement the move-specific functionality. I'm not sure
> what's the best strategy is for testing the class and subclasses.

I tend to give the tests a structure similar to the implementation, i.e.
the test units correspond to the functional units.

In your case, I would have tests verifying the correct functioning
of the base class and tests verifying that of the subclasses.

When an integration module uses the (already tested) services of
another module (as your subclasses use the services of the base class),
I try to avoid retesting the other modules functionality - but asume
in my new tests that the other (used) modules behave as expected.
This often significantly reduces the test complexity.

I your setup with base class and subclasses this implies that I
usually test only new and overridden methods in the subclasses.


In your case, you could also inherit your subclasses' test case
classes from that of your base class. This would lead to a reexecution
of the base class tests as part of the tests for each subclass.

I follow this route when a subclass has overridden base class methods
in a potentially sensible way.