I'm writing test cases using XCTest framework provided by apple. I come up with situation where i want to mock local variables allocated inside the function like this below
-(void)myFunction{
A* a = [[A alloc] init];
}
from my testcase class i want to mock class A inside my function testMyFunction . Is there any way to do it without using OCMock.
If it's okay to create the instance first, then inject it using normal Dependency Injection techniques.
But if you need to ensure that the instance won't be created until it's needed, you have a few choices:
Inject a class, as #dasdom says. Then call its initializer when you need it.
Inject a block that acts as a Factory. Call it when you need it.
For more complex initialization: inject a Factory. I'd typically make this conform to a protocol, to make replacements clear.
You could inject the class to be used in the method into the system unter test. In the test you can use a different class.
Related
We have a system which has a lot of model objects (e.g. Car, Pedestrian, Road, ...)
Currently all of them have managers (CarManager, PedestrianManager, RoadManager) that return a singleton of the respective class.
An alternative proposed is to have a ManagerFactory singleton that can return instances of CarManager, PedestrianManager, RoadManager. (e.g. ManagerFactory.getInstance().getCarManager())
We also write test for the project and the concern was that if we will use Dependency Injection we will need an actual instance of an object to inject managers.
Is this alternative a good one? Would you change the singleton into something else in this case?
A singleton directly or a singleton factory are basically the same thing - an opaque reference to something - a hidden dependency. With a global text search you can find these dependencies so neither option makes the situation better or worse.
Dependency injection means that you're publicly declaring that for instance A to work it needs an instance of B (or an instance which conforms to protocol C is a better dependency situation). This requires that you instantiate B somewhere and pass it to A.
From a test point of view dependency injection is far superior, because you generally want to create a mock version of B and use that to test A. The test injects the instance to use. Testing singletons is a pain...
So, ideally, the first class involved would create an instance of B and pass it to the other classes that need it, and that instance gets passed on from there.
If I have a class HelperClass that I'd like to use within a saga, I'd like to be able to inject an IHelperClass into the constructor.
The problem I'm running into is that sagas appear to be instantiated with an empty constructor; so while I can create a constructor that takes IHelperClass and use it in unit tests, the framework will always call the parameterless constructor.
I think I could use property injection, but since this helper class is "necessary," my understanding is that property injection (assuming it would work) is not a best practice.
So how can I do this without taking a hard dependency on the concrete HelperClass implementation?
You don't have to worry about the "necessity" of the help object in the context of the saga since no other code will be instantiating the saga directly.
In short, you can use property injection without concern here.
I have a base class and a few different subclasses set up to instantiate as change-tracking proxies, and I’d like to use the DbSet.Create(Type) method to create additional proxies to add to my Model.
My application was developed before Code First became available, so before, when I created these objects, I’d use a parameterized constructor to initialize both the object and its base member variables and properties.
Will Entity Framework allow me to create a change-tracking proxy using a constructor containing a parameter list? Would I be able to pass some of these parameters to the base class (proxy) as well? (I’d like to stick with the Object Oriented paradigm if I can because it’ll make the code easier to maintain.) If you can show me how to use parameterized constructors to do this, I’d be grateful.
Thanks,
EF cannot use parametrized constructors. You must always provide parameterless constructor (but it doesn't have to be public).
I inserted this line into my init() of my BootStrap class
Integer.metaClass.minutes = { 60000L * delegate }
I was then not able to use it from a Job class (Quartz plugin). Do I put this line of code somewhere else to make it a global modification?
I was also wondering the best way to make a function available inside all classes in Grails.
Like a global function. Would it be to extend the Object metaclass? or is there a better way?
Do I put this line of code somewhere else to make it a global modification?
Use the DelegatingMetaClass
I was also wondering the best way to make a function available inside all classes in Grails. Like a global function. Would it be to extend the Object metaclass? or is there a better way?
If you want the function to be an instance method of all classes, then you must add it to the metaClass of Object (see above). If not, simply add the function as a static method of a class, i.e. the same way you make functions globally accessible in Java.
Say I have a class called PermissionManager which should only exist once for my system and basically fulfills the function of managing various permissions for various actions in my application. Now I have some class in my application which needs to be able to check a certain permission in one of its methods. This class's constructor is currently public, i.e. used by API users.
Until a couple of weeks ago, I would have simply had my class call the following pseudo-code somewhere:
PermissionManager.getInstance().isReadPermissionEnabled(this)
But since I have noticed everyone here hating singletons + this kind of coupling, I was wondering what the better solution would be, since the arguments I have read against singletons seem to make sense (not testable, high coupling, etc.).
So should I actually require API users to pass in a PermissionManager instance in the constructor of the class? Even though I only want a single PermissionManager instance to exist for my application?
Or am I going about this all wrong and should have a non-public constructor and a factory somewhere which passes in the instance of PermissionManager for me?
Additional info Note that when I say "Dependency Injection", I'm talking about the DI Pattern...I am not using any DI framework like Guice or Spring. (...yet)
If you are using a dependency-injection framework, then the common way to handle this is to either pass in a PermissionsManager object in the constructor or to have a property of type PermissionsManager that the framework sets for you.
If this is not feasible, then having users get an instance of this class via factory is a good choice. In this case, the factory passes the PermissionManager in to the constructor when it creates the class. In your application start-up, you would create the single PermissionManager first, then create your factory, passing in the PermissionManager.
You are correct that it is normally unwieldy for the clients of a class to know where to find the correct PermissionManager instance and pass it in (or even to care about the fact that your class uses a PermissionManager).
One compromise solution I've seen is to give your class a property of type PermissionManager. If the property has been set (say, in a unit test), you use that instance, otherwise you use the singleton. Something like:
PermissionManager mManager = null;
public PermissionManager Permissions
{
if (mManager == null)
{
return mManager;
}
return PermissionManager.getInstance();
}
Of course, strictly speaking, your PermissionManager should implement some kind of IPermissionManager interface, and that's what your other class should reference so a dummy implementation can be substituted more easily during testing.
You can indeed start by injecting the PermissionManager. This will make your class more testable.
If this causes problems for the users of that class you can have them use a factory method or an abstract factory. Or you can add a parameterless constructor that for them to call that injects the PermissionManager while your tests use another constructor that you can use to mock the PermissionManager.
Decoupling your classes more makes your classes more flexible but it can also make them harder to use. It depends on the situation what you'll need. If you only have one PermissionManager and have no problem testing the classes that use it then there's no reason to use DI. If you want people to be able to add their own PermissionManager implementation then DI is the way to go.
If you are subscribing to the dependency injection way of doing things, whatever classes need your PermissionManager should have it injected as an object instance. The mechanism that controls its instantiation (to enforce the singleton nature) works at a higher level. If you use a dependency injection framework like Guice, it can do the enforcement work. If you are doing your object wiring by hand, dependency injection favors grouping code that does instantiation (new operator work) away from your business logic.
Either way, though, the classic "capital-S" Singleton is generally seen as an anti-pattern in the context of dependency injection.
These posts have been insightful for me in the past:
Using Dependency Injection to Avoid Singletons
How to Think About the "new" Operator with Respect to Unit Testing
So should I actually require API users to pass in a PermissionManager instance in the constructor of the class? Even though I only want a single PermissionManager instance to exist for my application?
Yes, this is all you need to do. Whether a dependency is a singleton / per request / per thread or a factory method is the responsibility of your container and configuration. In the .net world we would ideally have the dependency on an IPermissionsManager interface to further reduce coupling, I assume this is best practice in Java too.
The singleton pattern is not bad by itself, what makes it ugly is the way it's commonly used, as being the requirement of only wanting a single instance of a certain class, which I think it's a big mistake.
In this case I'd make PermissionManager a static class unless for any reason you need it to be an instanciable type.