How far should I apply the "isolated" principle in a unit test?

Hello everyone!

I am a former QA engineer (2 years professional experience - I have mostly done E2E tests), now software developer, working on a Django/React app.

I have no experience in unit testing and I have had discussions with other devs regarding unit testing. Here is my use case :

I have this django method (naming and type hints are for helping you understand the outputs):

def my_function_to_test(self, request):
	# My logic here
	return custom_fuction_to_transform_as_csv(my_logic_as_dict)

# Util method used multiple times throughout my app
def custom_fuction_to_transform_as_csv(logic_to_transform: dict) -> csv_outcome_as_http_response:
	# transform my dict into a csv
	return HTTPResponse(csv_outcome)

While writing my unit test, I wanted to patch the custom_fuction_to_transform_as_csv function to return the unmodified dict to only test my method logic. My thoughts were that this function should be tested separately as it is used throughout the app.

My colleague was arguing that we should test the full output of the method after being transformed into csv response.

  • Do you have thoughts/experience regarding that?
  • Any good ressources to recommend?

Note: Do not take the code syntax into consideration.



Your “# My logic here” seems to be the core of your program (application / usecases-entities).

If this core really really thin, as of now, you probably can do a good job by simplying creating test doubles for the HTTP calls. This way you won’t be depending on external components, and keep the feedback of the automated check pretty specific.

However, as this core gets more complex, more complicated and brittle will the automated check with this type of test double. If your core is more important, you can create automated checks for the primary and secondary adapters and others automated checks specifically for the core.

There are not “right answer” here - you have to do a benefit-cost analysis focused on the clients of the automated check: The developer, who is worried about making changes that produce unexpected consequences.


Thanks a lot for that! I’ll test and see (pun intended)

1 Like