We have a context of the application which is a static class named Holder contai
ID: 645811 • Letter: W
Question
We have a context of the application which is a static class named Holder containing several static properties initialized by objects that are used throughout the application.
All over the unit tests we need to initialize the context by mocks. In the current implementation, the context defense itself from reinitializing, so it contains Singletons. Because of that all tests share mocks, hence they take a responsibility to correctly clear them, I mean to clear their's behaviour.
What do you think about is it normally to have such a shared state between unit tests? And if you consider that as a bad practice, than I'll be appreciated for some advices.
Update. I'm sorry for misleading. One of the most important thing to mention is that I can't recreate many times the inner state of the Holder class. What options do I have in such a case?
Explanation / Answer
I had a similar problem with my code with global state via singelton.
As @Thomas-Junk-s and @SHODAN-s comment suggested i refactored my code to make the static global state non-static through constructor Dependency injection.
Example
original code
public static class Global {
public static int getSomeGlobalState() {...}
}
public class MyClass {
public MyClass(...) {...}
public myFunction(....) {
....
int i = Global.getSomeGlobalState()
....
}
}
refactored static global method to nonstatic global method
public class Global {
private Global global = new Global();
// singelton to keep old code compatible
public static Global getGlobal() {return global;}
// not static anymore
public int getSomeGlobalState() {...}
}
public class MyClass {
public MyClass(...) {...}
public myFunction(....) {
....
// replacing call to static member Global.getSomeGlobalState()
int i = Global.getGlobal().getSomeGlobalState()
....
}
}
refactored removed depency to static class Global from method myFunction to constructor
public class MyClass {
Global global;
// depricated constructor compatible with old api.
public MyClass(...) {this(..., ...;Global.getGlobal());}
// new constructor to be used in future
public MyClass(..., Global global) {...;this.global=global;}
public myFunction(....) {
....
int i = global.getSomeGlobalState()
....
}
}
after introducing a di-container: refactored to replace static singelton class Gloal to container
public class Global {
public Global() {...}
public int getSomeGlobalState() {...}
}
public class MyClass {
public MyClass(..., Global global) {...;this.global=global;}
public myFunction(....) {
....
int i = global.getSomeGlobalState()
....
}
}
Each refactoring made shure that the code, that ueses MyClass needs no modification.
In the last refactoring i added a di-container that is responsible for creating a singelton Global-Class and that injects the global instance into its customers like MyClass this way the old MyClass constructor could be removed.
[update 2014-12-11]
if you donot want to add a dependency all over the codebase as your comment suggests you can onmit the last refactoring step:
public class MyClass {
// constructor used in consuming classes.
public MyClass(...) {this(..., ...;Global.getGlobal());}
// constructor used for unittests where you can replace global.
public MyClass(..., Global global) {...;this.global=global;}
}
Related Questions
drjack9650@gmail.com
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.