Question

I have a method that is called on an object to perform some business logic and add it to the database.

The object is a Transaction, and part of the business logic requires searching the databses for related accounts and history items on the account.

There are then a series of comparisons and operations that need to bring back information from the account and apply it to the transaction before the transaction is then passed on to other people and written to the database.

The only way I can think of for testing this currently is within the test to create an account and the relevant history information, then to construct a transaction for each different scenario and capture the information written to the DB for the transaction and information being passed on, however this feels like its testing way too much in one test. Each scenario would be performed in a separate unit test, with the test construction refactored out into separate methods, but the actual piece of code targetted by the test is over 500 lines long.

I guess this question is more about refactoring than unit testing, but in this case they go hand in hand.

If anyone has any advice (good or bad) then I’d be glad to hear it.

EDIT:

Pseudo code:

Find account for transaction 
Do validation on transaction codes and values 
Update transaction with info from account 
Get related history from account Handle different transaction codes and values (6 different combinations, each with different logic) 
Update the transaction again with new account info (resulting from business logic) 
Send transaction to clients

Answer 1

I would appreciate it if you had some pseudocode on this question, but just following it over I would:

• Create interfaces for the data access objects that directly access the database – this way you can pass in an object that only pretends (e.g., mocks) that it accesses the database. This object would then return results consistent with the results your database would return, without actually doing any DB call. Your object could also simulate scenarios such as rolling back data to its original state.
• Extract each “scenario” into a single method each – that is the essence of a unit. If your method is 500 lines long then there must be contiguous blocks in there that can be extracted. Write a unit test for each, if appropriate.
• If your unit test is testing too much, that probably means your method is doing too much – You can extract methods by identifying the different things you are testing and then putting them in their own methods. Rinse and repeat until you only need one test for each method.
• Transactions “passed on to other people” sounds like a code smell – a transaction in and by itself should only be one contiguous unit. If you need different users to finish your transaction, you’re doing too much; keep track of your data’s state on the DB instead, in terms of flags or such, not in terms of a DB transaction.