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.
Win a copy of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams this week in the Reactive Progamming forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

How to design a test where the same scenario repeats itself?

 
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

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?

Thank you for any comment.
 
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why couldn't you? Test code is refactorable just like "real" code.
 
Adrian Burlington
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
not sure I understand your reply. could you rephrase please
 
David Newton
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).
 
Adrian Burlington
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
David Newton
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Adrian Burlington
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thank you!
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Seems close to the Object Mother pattern: http://martinfowler.com/bliki/ObjectMother.html

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 moth suit and wings road is much more exciting than taxes. Or this tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!