A class that is resolved as
builder.Resolve<IMyInterface>
Can be faked like this (for testing)
builder.RegisterType<MyFakeClass>().As<IMyInterface>();
But what if my class is resolved as
builder.Resolve<MyRealClass>
How to I fake this in autofac registeration? If I am using AutofacContrib.NSubstitute.
How can I achieve something like this
builder.RegisterType<MyFakeClass>().As<MyRealClass>();
As long as MyFakeClass inherits MyRealClass, that's all you have to do.
Related
Are static classes pretty much always frowned upon, or is there ever a good time to use them?
For example, would it make sense to implement something ubiquitous in your application like security in a static class? You could still use property injection on the static class to change out the implementation, and if you were to use something like MEF to inject the implementation then I would think it wouldn't get in the way of your tests.
I use static classes mainly for stateless helper classes and when I want to create extension methods. I try to avoid static classes that have state because as you mention it can get in the way of the tests.
Let's say you decide to add state to a static class. To test the methods of this class that depend on its state you will have to find a way to change this state during the tests. This means that you have to:
Prepare the state before each test.
Clear the state after each test.
This means that the class will need to offer a way (by means of internal methods or internal property setters) to alter its state which can be dangerous. If you want to create immutable classes or classes that encapsulate completely their implementation details then you will not be able to test them easily (if not at all) and your test might break more often from changes to the implementation. Even with MEF it will not be easy to do this.
Of course static class sometimes offer attractive solutions for problems like logging and,as mentioned in your question, security. In these cases I would go for a static class that delegates all calls to a private readonly field. This way the class of this field can be unit tested normally. You can then test the static class in your integration tests.
By the way have a look at .NET's design guidelines for static classes. It doesn't include anything relevant to your question but it includes valuable advice.
How to make it work?
I know that short questions aren't appreciated. But I have nothing to add this time.
update 1: As workaround I've made the constructor auxiliary, but I don't like this as it adds quite a lot of burden.
class Patient #Inject() (v1:C1) {}
Just found it here: http://www.scala-lang.org/node/3388
Is there any way to inject custom bindings in a class that's not an activity (a class that doesn't extends RoboActivitiy? Because everytime I try to inject it, I get a NullPointerException when accessing it.
I've solved it getting the injector and doing it by myself... but that's something I don't feel comfortable with.
Thanks!
If the class isn't itself created through injection, then obtaining the injector is the right (and only) way to do it. That's how RoboActivity (see onCreate()) does it in the first place. Objects created through injection get their members Injected by the injector.
Is there any way to create a fake from a System.Type object in FakeItEasy? Similar to:
var instance = A.Fake(type);
I try to write a fake container for AutoFac that automatically return fakes for all resolved types. I have looked in the code for FakeItEasy and all methods that support this is behind internal classes but I have found the interface IFakeObjectContainer that looks pretty interesting, but the implementations still need registration of objects that is the thing that I want to come around.
As of FakeItEasy 2.1.0 (but do consider upgrading to the latest release for more features and better bugfixes), you can create a fake from a Type like so:
using FakeItEasy.Sdk;
…
object fake = Create.Fake(type);
If you must use an earlier release, you could use some reflection based approach to create a method info for the A.Fake() method. (since it's about auto mocking this shouldn't be a problem really).
This is best done using a registration handler. You should look into how AutofacContrib.Moq implements its MoqRegistrationHandler. You'll see that it is actually using the generic method MockRepository.Create to make fake instances. Creating a similar handler for FakeItEasy should be quite simple.
Hi I am new to AspectJ and I would like to find out if creating variants of a class using Aspects - I will create another instance of the class as well?
I am guessing that the question is, if I am adding aspects would a new class be created.
The answer is no, as the weaving, either when compiling or at run-time, using AspectJ, will add the changes to the classes that are affected by the aspects, so there is no new class created, it is just that the byte code for the original class and the final class are different.
What do you mean by variants?
If you are asking if AspectJ instantiates copies of your class, the answer is no.
AspectJ uses a design pattern called proxy to intercept calls to your class.