Kiedy zachodzi znaczące nakładanie się w konfiguracji testu, może sprawić, że rzeczy DRY będą używać dziedziczenia. Ale to powoduje problemy z niepotrzebnego powielania wykonanie testu:Dlaczego testy w klasach pochodnych powodują ponowne uruchomienie testów klasy nadrzędnej?
from unittest import TestCase
class TestPotato(TestCase):
def test_in_parent(self):
print 'in parent'
class TestSpud(TestPotato):
def test_in_child(self):
print 'in child'
Testowanie ten moduł uruchamia test_in_parent
dwukrotnie.
$ python -m unittest example
in parent
.in child
.in parent
.
----------------------------------------------------------------------
Ran 3 tests in 0.000s
OK
Dlaczego? Czy to według projektu? Czy można go wyłączyć, konfigurując program testowy w określony sposób?
Mogę obejść ten problem, przenosząc program instalacyjny na nieodkrytą klasę, a następnie korzystam z wielu dziedziczeń, ale wydaje się on nieco hacky i niepotrzebny.
uwaga: sam problem występuje w innych biegaczy, takich jak nos (nosetests -s example.py
) i pytest (py.test example.py
)
Bo oni dziedziczą metody badań swoich rodziców, więc gdy 'unittest' przegląda ich' dir' (lub '__dict__' czy cokolwiek to robi) dla metod rozpoczynających 'test_' znajduje również odziedziczone. Nie sądzę, że rozwiązanie tego wymaga * wiele * dziedziczenia; streszczenie, co do trzeciej, nieodwracalnej klasy, bez metod "testowych", i obaj dziedziczą ją. – jonrsharpe
Introspekcja podklasy posiadającej klasę nadrzędną, która zawiera metody poprzedzone przez test, pokaże podklasę tymi metodami. To jest Python OOP. Nie sądzę, aby przenoszenie metod konfiguracji do mixin lub jako oddzielnej klasy bazowej w ogóle wydawało się być hackowate i być może DRYER – dm03514
Wydaje się, że to świetny przypadek użycia dla mixinów dla różnych "grup" testów, aby dynamicznie stworzyć dokładny test, którego potrzebujesz. ..tree-dziedziczenie nie wygląda tutaj jak właściwy model. – Shashank