You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Another way to get rid of staticness of the TmcUtil and the SettingsIo would be to add
getters for them in CliContext. Which could be replaced with Mockito spying or giving them
in the constructor.
Third way to fix the static classes could be dependency injection library like Guice,
but I don't have a clue how to integrate it easily into our project.
The text was updated successfully, but these errors were encountered:
Salmela
changed the title
Should we replace most of the PowerMocking with singleton pattern?
Should we replace most of the PowerMocking with singleton patterns?
Jul 9, 2016
Is it really a good idea to replace static classes with instances? I thought we were moving away from this when I refactored SettingsIo and CourseInfoIo.
The unit testing of static classes is bit of a pain. But we have now tests for nearly all of the code so It would take lot of time to change the unit tests. And I think there is more important stuff to be done here.
Also I unit tested some non-static util methods and their testing wasn't as easy as I would have hoped.
We could replace most of the static classes with singletons like this:
https://gist.github.com/Salmela/a9dcedfeb055249b72110e2022ba00c9
Another way to get rid of staticness of the TmcUtil and the SettingsIo would be to add
getters for them in CliContext. Which could be replaced with Mockito spying or giving them
in the constructor.
Third way to fix the static classes could be dependency injection library like Guice,
but I don't have a clue how to integrate it easily into our project.
The text was updated successfully, but these errors were encountered: