CODEWITHSUNDEEP
junitmockingejb-3.0
Muhammad Hewedy
Muhammad Hewedy

Reputation: 30078

When and why to use Mocking when testing EJBs

as appears in my question, I am confused about when and why to use mock objects when testing ejbs.

I am using plain JUnit and I find it works find with me, but I know it is not the all story.

Example:

@Stateless(name = "MyService")
public class MyBean extends BaseBean implements MyService
{
    public MyBean()
    {
    }

    public List<Category> getAllMainCategories()
    {
        //Category.findAll is a named query defined in Category entity
        return (List<Category>) em.createNamedQuery("Category.findAll").getResultList();
    }
}

And here's the test class:

public class MyServiceTest
{

    MyService service;

    @Before
    public void setUp() throws Exception
    {
        Context context = new InitialContext();
        service = (MyService) context.lookup("MyService");
    }

    @Test
    public void getAllMainCategories() throws Exception
    {
        assertNotNull(service);
        assertTrue(service.getAllMainCategories().size() > 0);
    }

}

As you see, I am doing unit testing for the session beans without the need for mock objects... so is this fully true, or i am lacking some thing?

Upvotes: 2

Views: 1188

Answers (2)

kriss
kriss

Reputation: 24207

You may have a look here (Martin Fowler blog) for Mocks related information.

Mock are used when you want to test code that has side-effect dependency. Calls to some service library, like DAO as another poster suggested, is a typical use. However, using mocks is never mandatory. In the DAO case an alternative could be to provide to your tested class some DAO wrapper object. In the test case you would provide another kind of DAO wrapper object that generates controled results. This method to avoid mocks is called "dependency injection" and gives the same benefit than mocks (really it's the same thing as using mock libraries, but made "by hand"). But in some cases using dependency injection instead of Mocks library is a bit awkward (you have to define some wrapper object you can derive instead of using the standard one).

Personaly I do not much like Mocks and try to avoid using them when possible. Reasons why I dislike them are because they easily lead to tests that doesn't fail when behavior of external API change, yes it's true unit tests, but too solid for my taste. Another point is because using mocks we tend to test internal behavior of what I believe should be a black box, but Mocks also have great fans.

Upvotes: 0

hvgotcodes
hvgotcodes

Reputation: 120268

You mock when you want to test something that has a dependency in isolation. For example, if a service uses a DAO, when you unit test the service, you mock the DAO so you can be sure any test failures are happening because of the service code, and not the DAO code. To say it another way, if you do not mock the DAO, and your service test fails, you need to find out if the test failed because the DAO call failed, or because of the service code.

Also, using mocks simplifies the testing, because you have a constant amount of test setup. As the number of dependencies grows, it can be a real pain to satisfy all the requirements the dependencies need. As opposed to using mocks, where the only dependency you need to satisfy is setting up the expectations in your mock framework.

Upvotes: 1

Related Questions