Re: Get hold of parameter to mocked object
Mattias,
I think I understand what you mean.
This is just my opinion, but from my personal learning experience, if a
piece of behaviour is not easily testable, it probably means the code
needs to be refactored. This is what TDD excels at forcing you to.
refactoring possible poor design.
To me, because this is not easily testable it highlights that your
business logic should not be interested in checking that the values of
domain objects are correct.
Your method should probably just be:
OrderCreator.createOrder(order);
and then assert that the order creates calls save on the DAO.
Setting the values of your domain object POJO (order) should probably be
done in a much higher level such as a Struts action, or Servlet.
And when you test your DAO you can test
1. That all the values nessessary in the domain object have been set to
legal/acceptable values.
or
2. That exceptions from your persistance framework are correctly handled
if a POJO is passed with illegal values.
Thats the kinda way we do it in here.
Chris
> I think that is what I want to do.
>
> To put some more details into my example, I want to test business logic.
> The output of the business logic is new/updated data, stored via DAOs.
> There is no return value or anything else to test on.
> Say for example that I want to verify that OrderCreator.createOrder(1,
> 2, 3) actually does create an order for customer 1 ordering article no.
> 2 at a quantity of 3.
> My plan was to use jMock (since there is a lot of supporting DAO
> communication going on in the actual business logic), and after calling
> the method I want the test to examine the resulting Order instance which
> was passed to the (mocked) OrderDAO by the tested business logic.
>
> Is this not the way to go?
> Do I need to create a dummy implementation of the DAO instead, that does
> assertions in its save() implementation???
>
> (I agree that the test of the DAO implementation is a totally different
> matter)
>
> </Mattias>
>
>
> chris@... wrote (2009-08-06 14:51):
>> Mattias,
>>
>> In my experience, are you sure thats what you want to be testing for?
>>
>> You should only be expecting that the DAO's "save" is being invoked with
>> the order.
>>
>> Anything further would then be getting tested in the implementation's
>> test
>> class i.e. "OrderDAOImplTest", and not in this test.
>>
>> Sorry if I have misunderstood your intentions.
>>
>> Chris
>>
>>
>>> What is the recommended practice for getting hold of the parameter
>>> passed to a mock object, for further testing.
>>>
>>> An example of what I want to do:
>>>
>>> OrderDAO orderDAO = context.mock(OrderDAO.class);
>>>
>>> checking(new Expectations() {
>>> {
>>> oneOf(orderDAO).save(with(any(Order.class)));
>>> }
>>> });
>>>
>>> doSomethingThatCreatesAndSavesOrder();
>>>
>>> Order order = ...; // The order passed to the mocked OrderDAO.save()
>>>
>>> // Regular jUnit tests
>>> assertEquals("1", order.getCustomer());
>>> assertEquals(3, order.getNoOfLines());
>>> ...
>>>
>>> I know I can do this using custom matchers:
>>>
>>> ...
>>> oneOf(orderDAO).save(with(allOf(
>>> any(Order.class),
>>> Matchers.hasProperty("customer",
>>> org.hamcrest.CoreMatchers.equalTo("1") // (Need to be declared as local
>>> variable for generics to work)
>>> )));
>>> ...
>>>
>>> but if the test fails, the error does not include the specific test
>>> that
>>> failed but only an "unexpected invocation".
>>>
>>> The solution that I have come up with would be to create a Matcher that
>>> remembers the object it is asked to match, which could then be accessed
>>> for further testing.
>>> Seems a bit ugly though. My gut tells me somebody should have thought
>>> about this already.
>>> Is there a better way???
>>>
>>> --
>>>
>>> </Mattias>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
RSS Feed