Pytest wohin mit den erwarteten Daten

Test-Funktion, die ich brauche, um die übergabe von Parametern und die Ausgabe entspricht dem erwarteten Ausgang.

Es ist einfache wenn-Funktion die Antwort ist nur eine kleine Palette oder ein einzeiliger string, die definiert werden kann, innerhalb der test-Funktion, aber angenommen, die Funktion, die ich testen ändert eine config-Datei, die kann riesig sein. Oder das sich daraus ergebende array ist etwas 4 Linien lang, wenn ich es definieren explizit. Wo muss ich das speichern, dass so meine tests sauber bleiben und leicht zu pflegen?

Recht wenn jetzt der string", ich lege einfach eine Datei in der Nähe der .py test und tun open() es im test:

def test_if_it_works():
    with open('expected_asnwer_from_some_function.txt') as res_file:
        expected_data = res_file.read()
    input_data = ... # Maybe loaded from a file as well
    assert expected_data == if_it_works(input_data)

Sehe ich viele Probleme mit einem solchen Ansatz, wie das problem der Aufrechterhaltung dieser Datei up-to-date. Es sieht schlecht aus als gut.
Ich kann die Dinge wahrscheinlich besser, wenn diese in eine Vorrichtung:

@pytest.fixture
def expected_data()
    with open('expected_asnwer_from_some_function.txt') as res_file:
        expected_data = res_file.read()
    return expected_data

@pytest.fixture
def input_data()
    return '1,2,3,4'

def test_if_it_works(input_data, expected_data):
    assert expected_data == if_it_works(input_data)

Dass nur verschiebt das problem an einen anderen Ort und in der Regel brauche ich, um zu testen, ob die Funktion funktioniert bei leeren input, input mit ein einzelnes Objekt oder mehrere Objekte, also ich müsste eine große Leuchte, inklusive drei Fällen eine oder mehrere VORRICHTUNGEN. In den Ende-code wird ziemlich chaotisch.

Wenn eine Funktion erwartet eine komplizierte Wörterbuch als Eingang oder zurück gibt das Wörterbuch von der gleichen enormen Größe test-code hässlich wird:

 @pytest.fixture
 def input_data():
     # It's just an example
     return {['one_value': 3, 'one_value': 3, 'one_value': 3,
     'anotherky': 3, 'somedata': 'somestring'], 
      ['login': 3, 'ip_address': 32, 'value': 53, 
      'one_value': 3], ['one_vae': 3, 'password': 13, 'lue': 3]}

Es ist ziemlich schwer zu Lesen tests mit solchen VORRICHTUNGEN und halten Sie up-to-date.

Update

Suche nach einer Weile fand ich eine Bibliothek, die gelöst ein Teil ein problem, wenn statt des großen config-Dateien hatte ich große HTML-Antworten. Es ist betamax.

Zur einfacheren Verwendung erstellt habe ich eine Leuchte:

from betamax import Betamax

@pytest.fixture
def session(request):
    session = requests.Session()
    recorder = Betamax(session)
    recorder.use_cassette(os.path.join(os.path.dirname(__file__), 'fixtures', request.function.__name__)
    recorder.start()
    request.addfinalizer(recorder.stop)
    return session

So, jetzt in meinen tests benutze ich nur die session Vorrichtung, und jede Anfrage, die ich mache, die serialisiert werden automatisch auf die fixtures/test_name.json - Datei, damit ich das nächste mal den test auszuführen, anstatt eine echte HTTP-request-Bibliothek lädt Sie aus dem Dateisystem:

def test_if_response_is_ok(session):
   r = session.get("http://google.com")

Es ist ganz praktisch, weil um diese Geräte up-to-date, ich brauche nur zum reinigen der fixtures Ordner und führen Sie erneut meinen tests.

  • Sehen Sie es aus Sicht der Entwickler, wer hat ein TC-Fehler und muss um zu Debuggen. Er hat einen Namen der Testfälle, so geht er in die Funktion mit diesem Namen. Wenn Sie halten die zu erwartenden Daten getrennt, werden Sie ihn zu zwingen, springen hin und her, um es zu vergleichen. Wann immer Sie können, halten Sie test-Eingang und erwartet Eingaben innerhalb eines Testfalls oder so nahe wie möglich, IMHO.
  • also, was ist Ihr Vorschlag? Halten Sie große Brocken von Daten in den Körper der test-Funktion? Was, wenn die binary zum Beispiel?..
  • binäre nicht Lesen, na ja, so ist es eine andere Geschichte. Ich sage nur, dass in Prüfungen Aufbewahrung der Nähe verwenden, ist mindestens so viel wichtiger als TROCKEN. Es hängt alles von dem Fall. Sicher, ich schlage vor, Sie Rücken deine Daten... diese return du geschrieben hast ist wirklich hässlich und schwer zu verstehen.
InformationsquelleAutor Glueon | 2015-04-14
Schreibe einen Kommentar