Ich bin ziemlich neu in Zend und Unit-Tests im Allgemeinen. Ich habe eine kleine Anwendung entwickelt, die Zend Framework 2 und Doctrine verwendet. Es hat nur ein Modell und einen Controller und ich möchte einige Komponententests auf ihnen durchführen.
Folgendes habe ich bisher:
Base-Doktrin "Entity" -Klasse, die Methoden enthält, die ich in allen meinen Entitäten verwenden möchte:
%Vor%Meine 'config' Entität, die eine einzeilige Tabelle mit einigen Konfigurationsoptionen darstellt:
%Vor%Und mein Controller, der von der Entity lesen und schreiben kann:
%Vor%Aufgrund von Zeichenbeschränkungen konnte ich meine Komponententests nicht einfügen, aber hier sind bisher Links zu meinen Komponententests:
Für die Entität: Ссылка
Für den Controller: Ссылка
Einige Fragen:
Vielen Dank im Voraus!
Ihr Code scheint zwar solide genug zu sein, bietet jedoch einige Designfehler.
Zunächst empfiehlt Doctrine, Entitäten wie einfache, dumme Wertobjekte zu behandeln, und gibt an, dass die Daten, die sie enthalten, immer als gültig angenommen werden.
Dies bedeutet, dass jede Geschäftslogik wie Hydration, Filterung und Validierung außerhalb von Entitäten in eine separate Schicht verschoben werden sollte.
Wenn wir von Hydratation sprechen, anstatt selbst fromArray und toArray -Methoden zu implementieren, könnten Sie den mitgelieferten DoctrineModule\Stdlib\Hydrator\DoctrineObject Hydrator verwenden, der auch fehlerfrei mit Zend\InputFilter gemischt werden kann, um Filterung und Validierung durchzuführen. Dies würde das Testen von Entitäten viel weniger ausführlich machen, und dies ist wohl nicht so notwendig, da Sie den Filter separat testen würden.
Ein weiterer wichtiger Vorschlag von Doctrine Devs ist es, ObjectManager nicht direkt in Controller zu injizieren. Dies dient der Verkapselung: Es ist wünschenswert, Implementierungsdetails Ihrer Persistenzschicht in Controller zu verbergen und wiederum nur eine Zwischenschicht freizulegen.
In Ihrem Fall könnte all dies getan werden, indem Sie eine ConfigService -Klasse haben, die nach Vertrag entworfen wurde und nur die Methoden zur Verfügung stellt, die Sie wirklich brauchen (zB findAll() , persist() und andere handliche Proxies) verstecken Sie die Abhängigkeiten, die nicht unbedingt vom Controller benötigt werden, wie die EntityManager , Eingabefilter und ähnliches. Es wird auch zu leichterem Spott beitragen.
Wenn Sie eines Tages einige Änderungen an Ihrer Persistenzschicht vornehmen möchten, müssen Sie lediglich ändern, wie Ihr Entitätsdienst den Vertrag implementiert: Denken Sie daran, einen benutzerdefinierten Cache-Adapter hinzuzufügen oder Doctrines ODM anstelle von ORM oder überhaupt nicht Doctrine.
Ansonsten sieht Ihr Unit-Test-Ansatz gut aus.
TL; DR
Ihre Tests sehen uns sehr ähnlich. Es ist also nicht sofort klar, dass Sie es falsch machen. :)
Ich stimme zu, dass das ein bisschen komisch riecht, aber ich habe keine Antwort auf diese Frage. Unser Standard ist es, alle unsere Modelle "dumm" zu machen und wir testen sie nicht. Dies ist nichts, was ich empfehle, sondern weil ich nicht auf dein Szenario gestoßen bin, bevor ich nicht einfach raten möchte.
Sie scheinen ziemlich erschöpfend zu testen, obwohl ich wirklich empfehlen würde, das spöttische Framework auszuprobieren: Phake ( Ссылка ) Es hilft wirklich, Ihre Behauptungen von Ihrem Mocking zu trennen, und bietet eine viel besser verdauliche Syntax als die eingebauten phpunit Mocks.
viel Glück!
Tags und Links unit-testing php phpunit zend-framework2