I'm trying to implement a collection fixture where the work that the fixture needs to perform (in its constructor) requires a parameter. I want the fixture to be generic/reusable and it needs to know the Assembly of the unit being tested.
How can I parameterize a collection fixture, such that tests in the collection can give the fixture this "context?"
I ended up creating an abstract collection fixture, with a protected constructor that takes the necessary parameter (in my case, the Assembly). Then I defined small subclasses that have a no-arg constructor that calls the inherited one with the correct argument.
public abstract class BaseCollectionFixture<TFixture> : ICollectionFixture<TFixture>
where TFixture : class
{
protected BaseCollectionFixture(Assembly assemblyUnderTest)
{
// Do my fixture stuff with the assembly
}
}
[CollectionDefinition("Special tests")]
public class ConcreteFixture : BaseCollectionFixture<ConcreteFixture>
{
public ConcreteFixture() : base(typeof(MyClassUnderTest).Assembly) {}
}
Then I use it in a test like this:
public MyClassTests<ConcreteFixture> { ... }
Related
I´m working on a legacy spring boot project that makes a strong reuse of a DTO class in a generic controller and in multiple services:
#PostMapping
controller.input(#RequestBody MyTypeDto type) { ... }
service.resolve(MyTypeDto type) { ... }
processor.send(MyTypeDto type) { ... }
I want to start decoupling it by creating another endpoint and making MyTypeDto an abstract class.
My biggest concern under all is the compatility with jackson.
public abstract class MyTypeDto { ... }
public class AnotherTypeDto extends MyTypeDto { ... }
public class AndAnotherTypeDto extends MyTypeDto { ... }
Is it considered a good practice?
As it is implied on your question, you controller endpoint is generic, it takes the input, creates the type, pass it to service based on subtype. Otherwise, you will end up many endpoints which all doing is creating the subtype and pass it to service.
If Jackson is your concern, Jackson has mechanism for subtypes. Please note you have to send one additional field which act as the discriminator (in this example, it is called type to decide which sub type to create.
#JsonTypeInfo(use = Id.NAME, include = As.PROPERTY, property = "type")
#JsonSubTypes({#JsonSubTypes.Type(value = FirstSubDto.class, name = "First"),
#JsonSubTypes.Type(value = SecondSubDto.class, name = "Second")})
public abstract class MyTypeDto {
..
}
Consider a nested enum class, which is passed as argument to a member function of that class.
class VerboseClassName {
public:
enum class Unit {KG, TON};
void foo(Unit unit) { /*...*/ }
};
Using this type of construction always feels kinda awkward to me, as the class name has to be qualified even from within the method call.
void bar() {
VerboseClassName a;
a.foo(VerboseClassName::Unit::KG);
}
Would it make sense to consider the class scope available in calls to the classes members? Is there a technical reason why this would lead to trouble?
I am trying to implement DI with Castle Windsor. Currently I have a controller with overloaded constructors like this (this is an antipattern as described here: https://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=97):
public class MyController : ApiController
{
protected IStorageService StorageService;
protected MyController()
{
StorageService = StorageServiceFactory.CreateStorageService(User.Identity as ClaimsIdentity);
}
protected MyController(IStorageService storageService)
{
StorageService = storageService;
}
}
I am trying to get rid of the first constructor and have Castle Windsor handle the resolution of the storage service dependency.
I created a Castle Windsor installer class like this:
public class StorageServiceInstaller : IWindsorInstaller
{
public void Install(IWindsorContainer container, IConfigurationStore store)
{
container.Register(
Component.For<IStorageService>()
.UsingFactoryMethod(
() => StorageServiceFactory.CreateStorageService(User.Identity as ClaimsIdentity)));
}
}
The problem is that User (which has type IPrincipal) is a property on ApiController, so it's not accessible from the installer. How can I make this work?
Update:
#PatrickQuirk seems to be implying that there is a better way to do this using Castle Windsor without needing a factory at all.
My StorageServiceFactory looks like this:
public static class StorageServiceFactory
{
public static IStorageService CreateStorageService(ClaimsIdentity identity)
{
if (identity == null)
{
return null;
}
Claim providerKeyClaim = identity.FindFirst(ClaimTypes.NameIdentifier);
if (providerKeyClaim == null || string.IsNullOrEmpty(providerKeyClaim.Value))
{
return null;
}
StorageProviderType storageProviderType;
string storageProviderString = identity.FindFirstValue("storage_provider");
if (string.IsNullOrWhiteSpace(storageProviderString) || !Enum.TryParse(storageProviderString, out storageProviderType))
{
return null;
}
string accessToken = identity.FindFirstValue("access_token");
if (string.IsNullOrWhiteSpace(accessToken))
{
return null;
}
switch (storageProviderType)
{
// Return IStorageService implementation based on the type...
}
}
}
Is there a way to incorporate selecting the correct IStorageService into Windsor's dependency resolution and avoid the factory altogether? Or do I still need it?
I like #PatrickQuirk's solution, except that it seems odd to have to create a wrapper and corresponding wrapper interface for the factory just for the sake of dependency injection. Ideally I'd have the api controller's constructor take in an IStorageService as a parameter, which seems more intuitive/consistent with the field that actually needs to be set.
I don't think the multiple constructors is as much of a sin as the hidden dependency on StorageServiceFactory is, but I agree with your approach for the most part.
Instead of a factory method, pass a factory object into the class and have it create the storage service:
public class MyController : ApiController
{
protected IStorageService StorageService;
protected MyController(IStorageServiceFactory storageServiceFactory)
{
StorageService = storageServiceFactory.CreateStorageService(User.Identity as ClaimsIdentity);
}
}
And then define your factory interface and implementation:
public interface IStorageServiceFactory
{
IStorageService Create(ClaimsIdentity claimsIdentity);
}
public class StorageServiceFactoryImpl : IStorageServiceFactory
{
public IStorageService Create(ClaimsIdentity claimsIdentity)
{
return StorageServiceFactory.CreateStorageService(claimsIdentity);
}
}
This way, you have a single constructor and the dependency on the storage service factory is explicit.
Regarding your update:
...it seems odd to have to create a wrapper and corresponding wrapper interface for the factory just for the sake of dependency injection.
Well, that's kind of the point of dependency injection.
The wrapper I propose is solving two problems: it removes the need to call a static method from inside your class (hiding a dependency), and allows for delayed resolution (because your dependency relies on member data to be created).
If you have a way to change the dependencies of creating an IStorageService to not rely on a member of the class you're giving it to, then you could pass one in directly (provided you can tell Windsor how to create one).
Good day, I have a fairly simple question to experienced C# programmers. Basically, I would like to have an abstract base class that contains a function that relies on the values of child classes. I have tried code similar to the following, but the compiler complains that SomeVariable is null when SomeFunction() attempts to use it.
Base class:
public abstract class BaseClass
{
protected virtual SomeType SomeVariable;
public BaseClass()
{
this.SomeFunction();
}
protected void SomeFunction()
{
//DO SOMETHING WITH SomeVariable
}
}
A child class:
public class ChildClass:BaseClass
{
protected override SomeType SomeVariable=SomeValue;
}
Now I would expect that when I do:
ChildClass CC=new ChildClass();
A new instance of ChildClass should be made and CC would run its inherited SomeFunction using SomeValue. However, this is not what happens. The compiler complains that SomeVariable is null in BaseClass. Is what I want to do even possible in C#? I have used other managed languages that allow me to do such things, so I certain I am just making a simple mistake here.
Any help is greatly appreciated, thank you.
You got it almost right, but you need to use properties instead of variables:
public abstract class BaseClass {
protected SomeType SomeProperty {get; set}
public BaseClass() {
// You cannot call this.SomeFunction() here: the property is not initialized yet
}
protected void SomeFunction() {
//DO SOMETHING WITH SomeProperty
}
}
public class ChildClass:BaseClass {
public ChildClass() {
SomeProperty=SomeValue;
}
}
You cannot use FomeFunction in the constructor because SomeProperty has not been initialized by the derived class. Outside of constructor it's fine, though. In general, accessing virtual members in the constructor should be considered suspicious.
If you must pass values from derived classes to base class constructor, it's best to do it explicitly through parameters of a protected constructor.
I am currently implementing SiteMinder for the site, which looks for a key called SM_USER in the request header. I retrieve it using the function below:
public string ReadUser()
{
return HttpContext.Current.Request.Headers["SM_USER"];
}
I wish to test if functionality releated to this function work; I have already tried unit testing using a mock class so I am looking to create the key SM_USER in the request header. How can I do that?
I am implementing the application with MVC3.
As long as you are using HttpContext.Current you will not be able to test it as Unit Test will not have HttpContext.Current.
Try to use an Interface with method returning string, say ReadUser(). Implement this interface in a class in your application. Use the interface variable whichever class you are using this method in. In that class' default constructor set that interface variable value to 'new' implementer class. Add an overload of the constructor which will take a parameter of type interface and set that parameter to interface variable.
Now in your UnitTest project implement same interface in another class. In this implementation you can now pass whatever mock value you want test.
public interface IReadUserInfo
{ string ReadUser(); }
public class ReadUserInfo: IReadUserInfo
{
public string ReadUser()
{
return HttpContext.Current.Request.Headers["SM_USER"];
}
}
public class UserClass
{
IReadUserInfo userinfo;
public UserClass()
{
userinfo = new ReadUserInfo();
}
public USerClass(IReadUserInfo newuserinfo)
{
userinfo = newuserinfo;
}
}
public class TestReadUserInfo : IReadUSerInfo
{
public string ReadUser()
{ return "testvalue"; }
}
If ReadUser is the only value you are using from Request header, then this approach will solve the problem. However, if you using more values from Request object, you might want to mock entire request object in similar way.