State vs behaviour testing on code which doesn't cross integration boundaries

I have a method that has some data objects passed into it, does some calculations to populate previously empty fields on the objects based on the other fields and then sends back the results. This method does not really cross integration boundaries - the data objects are entities with a fairly complex tree of dependencies on other entities, but from this method's perspective the开发者_开发知识库y are just objects with state (thank you ORM).

It seems to me that unit testing this would require a check of state - set up some data, run the code to do the calculations and check the results. Is this a legitimate case for ignoring what seems to be across the board advice that tests should check behaviour, not state? Or am I misreading the test-driven literature somewhat?

I'd say you're testing the behaviour of the method which does the calculations, so it's not a problem.

Some people might suggest that having the behaviour in a separate method (as a service) and not on the classes which hold the data could be a code smell, but that's a different issue.

The behaviour is that given input state you get the expected output state. The unit tests should create dummy objects (possibly mocks) with known state, run the method under test and then check the output (in this case that is state on input parameter) is correct.