Encore maintenant j'utilise JUnit, je suis tombé sur EasyMock, je comprends que les deux sont dans le même but. Est-ce que ma compréhension est correcte?Junit et EasyMock compréhension clarifications
Quels sont les avantages d'EasyMock par rapport au Junit?
Lequel est le plus facile à configurer?
Est-ce que EasyMock a des limitations?
S'il vous plaît aidez-moi à apprendre
Ils ne sont pas la même chose
JUnit est un framework de test xUnit - Il a un coureur de test qui boucle sur vos suites de test, exécute chaque test unitaire automatisé et enregistre la résultats.
EasyMock est un mock-object framework. Il est utilisé pour remplacer les collaborateurs difficiles à installer avec des mannequins/faux/simulacres pour les aider à se concentrer sur le comportement que j'ai l'intention de tester.
par exemple. si mon SUT.AuditCustomers() appelle DAO.GetCustomer (databasePath), dans mon test je voudrais me concentrer sur la méthode AuditCustomers(), donc j'utiliserais un mockDAO qui ne lirait pas les clients de la base de données à la place renvoie des informations connues/Objets clients codés en dur pour un test facile. Cela a également l'avantage que n'importe quel bogue dans GetCustomer n'échoue pas le test pour AuditCustomers()
Je ne suis pas sûr mais je pense que JUnit et EasyMock au lieu d'être exclusifs l'un à l'autre sont censés fonctionner ensemble. JUnit L'idée est de tester une méthode donnée et donc d'injecter des instances fictives d'autres classes pour s'assurer que le test JUnit ne dépend pas du tout des autres méthodes de classe. Ce but de fournir des objets fantaisie dans JUnit est servi par EasyMock et d'autres créateurs similaires d'objets simulés. Une idée similaire est utilisée lors de l'utilisation de spring pour injecter des implémentations factices dans JUnit. EasyMock semble être prometteur, mais vous devriez évaluer si Spring ou d'autres générateurs d'objets proxy correspondent à votre scénario.
Quand j'explique les tests unitaires J'aime décrire comme une liste de phases:
jUnit est un cadre de test unitaire et fournit toutes les phases de test, à l'exception des attentes.Alternatives dans l'espace Java incluent:
Autres équivalents de langue comprennent:
Le concept de moquerie est ce ajouté la nouvelle phase des attentes, et depuis jUnit a vu la plupart de ses grands projets de développement avant le mouvement moqueur, ces caractéristiques ont été pas intégré dans le noyau, et un ensemble d'outils pour combler ce vide dans l'espace java ont ouvert. Ces bibliothèques comprennent
Toutes ces bibliothèques sont des compliments à l'un des cadres ci-dessus de tests unitaires I répertoriés, y compris jUnit. Ils ajoutent la possibilité de définir des objets fantaisie. Les objets fantômes reçoivent des "attentes" qui sont ensuite affirmées dans la phase Assertions. Chaque bibliothèque Mock accomplit cette façon légèrement différente, mais les principaux modèles sont
Personnellement, je suis fan de l'approche des attentes, qui est plus déclaratif, et moins sujette aux erreurs, car il nécessite moins de méthodes pour être appelé par l'implémenteur, mais c'est une préférence stylistique et non technique.
D'autres langues (puisqu'elles sont arrivées au monde des tests unitaires plus tard que java) n'ont pas cette séparation pour la plupart. La bibliothèque de tests unitaires et la bibliothèque de simulation sont une seule et même chose. C'est le cas dans phpunit, rspec. J'imagine que jUnit n'intégrera pas ce natif de sitôt, car il existe déjà un ensemble aussi riche de fausses bibliothèques alternatives.