I have an interface which wraps the functionality to create a shared memory and write to this shared memory.
public interface ISharedMemManager {
bool CreateSharedMemory(int size);
bool WriteToSharedMemory(byte[] buffer, int offset, int size);
}
A typical implementation of above interface which creates Memory Mapped file would be:
public class MemMappedFileManager : ISharedMemManager {
private Mutex mutex; //mutex that will guard the shared memory
private string name;
//constructor that inits mutex and memory name
bool CreateSharedMemory(int size) { ... } //creates shared memory
bool WriteToSharedMemory(byte[] buffer, int offset, int size) {
//Open handle to the memory mapped file
mutex.WaitOne();
//create view of memory mapped file
//write to that view stream
mutex.ReleaseMutex();
}
}
Here my implementation of WriteToSharedMemory
depends on the class global mutex. However in the testing code of this function, I totally want to avoid any mutex waiting because I will be creating a different memory mapped file for my test code. Also, acquiring and releasing a mutex is a costly process which will cause the test to slow down.
Should I totally remove the mutex as a class global variable and add that to the signature of the WriteToSharedMemory
in the interface and have the mutex as an optional parameter so that I could inject on function call. In this case I will have to modify the function code to check for optional mutex. Is this right? Also I get a feeling that my interface becomes more implementation specific by adding a mutex parameter. Also code becomes more messy with conditions, earlier it was much simpler.
Also to validate that the write operation was successful, in the test after calling the WriteToSharedMemory
we will read the memory mapped file and assert accordingly. The reading logic is part of the test now and the test doesn't seem simple any more. Is there a better and simpler way to test this scenario? I am filled with so many thoughts that I think getting an opinion is better.
Also I don't know what to call this test. Unit test or Integration test. I am actually writing test for one class or simply unit but at the same time my tests would be creating side effects as I am dealing with a resource.
Aucun commentaire:
Enregistrer un commentaire