This week's book giveaway is in the Reactive Progamming forum. We're giving away four copies of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams and have Adam Davis on-line! See this thread for details.
So...I need to test some functionality of a business logic. For example, I need to check a "resetUserPassword" method. To do this, I have to construct a User and then with the SecurityService invoke the resetUserPassword.
A user MUST be part of a *Company* and belong to a *Department*. So first I need to construct those objects and only then associate the User to those objects. Once I have those 3 - I can test the functionality.
What I'm doing today is this:
I realized then that this scenarios repeats in almost all my tests.
So I guess my question boils down to this: can I create a class called 'EmulateDB' and create all the objects and associations and only then handle the tests of my business logic functionality?
Is this a good way to do the testing or is there a better way to do that?
In non-test code we refactor all the time: when we see duplicated functionality we try to consolidate it in one place (or at least we *should*).
If we find ourselves repeating ourselves in test code shouldn't we do the same thing? If the functionality doesn't change across tests why *wouldn't* you want to refactor it out into its own code unit and maintain the setup code all in one place?
In a nutshell I'm asking you why wouldn't you refactor test code just like non-test code? With the setup code refactored all your tests can utilize a single codebase for their setup (unless the test needs something different, of course).
posted 10 years ago
Thank you David for your reply.
I understood from your post that the refactoring should also occur in the testing. So a solution like:
will be a good one because I can utilize EmulateDB in other tests. I simply wonder if this is an expectable solution in the Junit world or there's a different way to do so.
I think people set up their fixtures in many different ways--for something like this it seems like the quickest, easiest solution. There are other games that can be played with data providers etc, but for simple fixtures like this it seems like a reasonable solution.
There might be an alternative, though: often, the need for a complex test setup is a "code smell", pointing at the fact that the design is to tightly coupled.
So, how would you need to change the design, so that creation of all that objects wouldn't be necessary any more? (Often, it helps to introduce an indirection somewhere - perhaps in the form of an interface that then can mocked for the test.)
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
The moth suit and wings road is much more exciting than taxes. Or this tiny ad: