views:

264

answers:

4

Still Now I am using JUnit, I came across EasyMock, I am understanding both are for the same purpose. Is my understanding correct?

What are the advantages does EasyMock has over the Junit?

Which one is easier to configure?

Does EasyMock has any limitations?

Please help me to learn

+3  A: 

They are not the same thing

JUnit is a xUnit testing framework - It has a test runner that loops over your test suites, executes each automated unit test and records the results.

EasyMock is a mock-object framework. It is used to replace hard to setup collaborators with dummies/fakes/mocks to help focus on the behavior I intend to test.
e.g. if my SUT.AuditCustomers() calls DAO.GetCustomer(databasePath), in my test I'd like to focus on the method AuditCustomers(), so I'd use a mockDAO which does not read the customers from the database instead returns known/hardcoded Customer objects to easy testing. This also has the benefit that any bug in GetCustomer does not fail the test for AuditCustomers()

Gishu
A: 

I am not sure but I think JUnit and EasyMock instead of being exclusive to each other are supposed to work in tandem together. JUnit idea is to test a given method and therefore you want to inject dummy instances of other classes into it, to ensure the JUnit test is not dependent on other class methods at all. This purpose of providing mock objects in JUnit is served by EasyMock and other similar mock object creators. Similar idea is used when using spring to inject dummy implementations into JUnit.

EasyMock seems to be promising, but you should evaluate if Spring or some other proxy object generators fit your scenario.

Fazal
A: 

EasyMock is used together with JUnit. It's not an alternative to JUnit.

JUnit is the framework that defines how your test definitions look like and how they are executed, while EasyMock is used inside your tests.

EasyMock gives you the possibility to create runtime mocks of classes, so that you can use them in the tests instead of the real ones.

Bozho
+3  A: 

When I explain unit testing I like to describe them as a list of phases:

  • Test Setup : Define and Create all the Data and Objects you need for the tests
  • Expectations : Say what methods and parameters you expect to be executed during the test
  • Test : The actual behavior/method call you want to test
  • Assertions : Statements that make sure the outcome of the test were successful
  • Test Tear down : Destroy any side effects that occurred during the test

jUnit is a Unit Testing Framework and provides all but the Expectations phase of testing. Alternatives in the Java space include:

  • TestNG
  • jtest
  • jBehave (sort of)
  • jDave (sort of)

Other Language equivalents include:

  • PHP - phpUnit
  • Ruby - Test::Unit
  • Flash - FlexUnit

The concept of mocking is what added the new phase of Expectations, and since jUnit saw most of it's major development prior to the mocking movement, those features were not incorporated into the core, and a set of tools to fill that gap in the java space have opened up. Those libraries include

  • EasyMock
  • jMock
  • jMockIt

All of these libraries are compliments to any of the above Unit Testing frameworks I listed, including jUnit. They add the ability to define mock objects. Mock objects get "expectations" assigned to them, which are then asserted in the Assertions phase. Each Mock library accomplishes this slightly differently, but the major models are

  • Record Replay - EasyMock
  • Expectations - jMock, jMockIt

I personally am a fan of the Expectations approach, which is more declarative, and less error prone, because it requires less methods to be called by the implementor, but that is a stylistic preference not a technical one.

Other Languages (since they came to the unit testing world later than java) don't have this seperation for the most part. The Unit Testing Library and Mock Library are one and the same. This is the case in phpunit, rspec. I imagine jUnit will not be incorporating this natively any time soon, since there is already such a rich set of alternative mock libraries available.

Daniel Roop