Validierungen an sich sollten vertrauenswürdig sein, aber Sie sollten überprüfen, ob die Validierung vorhanden ist.
Mit anderen Worten, eine gute Möglichkeit, etwas zu testen, ist, als ob es eine Blackbox wäre, die die Tests von der Implementierung abstrahiert. So könnten Sie zum Beispiel einen Test haben, der prüft, dass ein Personenmodell nicht ohne gespeichert werden kann ein Name, aber es interessiert nicht, wie die Person-Klasse diese Validierung durchführt.
Es sollte ausreichen, zu akzeptieren, dass Bibliotheken wie ActiveRecord von den Entwicklern besser getestet werden, als sie es jemals sein werden: für sie ist es ein primäres Anliegen, für Sie ist es bestenfalls tangential.
Das soll nicht heißen, dass es keine Bugs geben wird - ich habe vor langer Zeit einen kleinen der MS SQL Server Adapter gefunden - aber die Art von Test, die Sie wahrscheinlich implementieren werden, ist höchst unwahrscheinlich, sie als sie auszusetzen sind am ehesten Randfälle. Wenn Sie tun einen Fehler finden, ist es natürlich sehr hilfreich, wenn Sie ihn mit einem Testfall melden, der ihn aufdeckt!
Ich würde ActiveRecord-Internals nur testen, wenn ich einen bestimmten Aspekt, den die Bibliothek implementiert, besser verstehen wollte. Ich würde diese explorativen Tests in keinem Anwendungsprojekt einschließen, da sie für das Projekt nicht relevant sind.
Im Allgemeinen sollten Sie Tests für Code schreiben, den Sie selbst schreiben: Wenn Sie leben oder versuchen, in einer TDD-Welt zu leben, sollten die Tests vorher geschrieben werden. Wenn Ihre Modelle Validierungsregeln haben, sollten Sie fast sicher Tests schreiben, um sicherzustellen, dass die Regeln vorhanden sind. In den meisten Fällen werden die Tests trivial sein, aber sie werden wirklich nützlich sein, wenn eine Zeile versehentlich irgendwann in der Zukunft gelöscht wird ...
Wie Mike schrieb, sollten Sie zumindest testen, ob die Validierung existiert. Es ist nur ein bisschen doppelte Buchführung (Gesundheitscheck), das ist einfach genug zu tun.
Abhängig von der Situation sollten Sie auch testen, ob Ihr Modell unter bestimmten Umständen gültig oder ungültig ist. Wenn Ihr Feld beispielsweise ein bestimmtes Format erfordert, testen Sie die gültigen und nicht gültigen Beispielformate. Es ist viel einfacher zu sehen, was dies bedeutet, indem Sie ein paar Beispiele in Ihren Tests lesen:
%Vor%Ja, die Validierungen sind gut getestet und zuverlässig genug. Aber Ihre korrekte Verwendung der Validierungen ist, was Sie überprüfen möchten.
Als Randnotiz erwähnt Ryan Biggs Blogpost has_and_belongs_to_many double insert , dass jemand auf einen Fehler stößt ActiveRecord (nicht im Zusammenhang mit der Validierung). Wie er hervorhebt, gehen Sie nicht davon aus, dass Rails keinen Bug haben kann, da wir wissen, dass es 900 offene Tickets für Rails gibt.
Aber der Hauptgrund, warum Sie einen Test schreiben, ist, zu überprüfen, ob Ihre Verwendung von ActiveRecord korrekt ist.
Tags und Links ruby unit-testing ruby-on-rails activerecord