Tag: mock

In-memory Orchestrate Local Development Database

I was talking with Tory Adams @BEZEI2K about working with Orchestrate‘s Services. We’re totally sold on what they offer and are looking forward to a lot of the technology that is in the works. The day to day building against Orchestrate is super easy, and setting up collections for dev or test or whatever are so easy nothing has stood in our way. Except one thing…

Every once in a while we have to work disconnected. For whatever the reason might be; Comcast cable goes out, we decide to jump on a train or one of us ends up on one of those Q400 puddle jumpers that doesn’t have wifi! But regardless of being disconnected from wifi, cable or internet connectivity we still want to be able to code and test!

In Memory Orchestrate Wrapper

Enter the idea of creating an in memory Orchestrate database wrapper. Using something like convict.js one could easily redirect all the connections as necessary when developing locally. That way development continues right along and when the application is pushed live, it’s redirected to the appropriate Orchestrate connections and keys!

This in memory “fake” or “mock” would need to have the key value, events, and graph store setup just like Orchestrate. With the possibility of having this in memory one could also easily write tests against a real fake and be able to test connected or disconnected without mocking. Not to say that’s a good or bad idea, but just one more tool in the tool chest doesn’t hurt!

If something like this doesn’t pop up in the next week or three, I might just have to kick off this project myself! If anybody is interested please reach out to me and let’s discuss! I’m open to writing it in JavaScript, C#, Java or whatever poison pill you’d prefer. (I’m not polyglot to limit my options!!)

Other Ideas, Development Shop Swap

Another idea that I’ve been pondering is setting up a development shop swap. I’ll leave the reader to determine what that means!  😉  Feel free to throw down ideas that this might bring up and I’ll incorporate that into the soon to be implementation. I’ll have more information about that idea right here once the project gets rolling. In the meantime, happy coding!

Stubbing a File Stream, Memory Stream, or Stream

Here’s the class that has a Func setup as a property. The reason this is setup, is so that the stream can actually be stubbed on the ComplianceReportingJob. Otherwise if the Stream was just being used as is, instantiated in the class, or passed in via injection, we still couldn’t get it mocked or stubbed. Especially if the class ComplianceReportingJob is under test.

[sourcecode language=”csharp”]
public class ComplianceReportingJob : IJob
{
readonly ITradeRepository tradeRepo;
readonly IFileSystem fileSys;

public ComplianceReportingJob(ITradeRepository tradeRepository, IFileSystem fileSystem)
{
tradeRepo = tradeRepository;
StreamedFile = filename => new FileStream(filename, FileMode.Create);
}

public Func<string, Stream> StreamedFile { get; set; }
}
[/sourcecode]

What we have here is the context being setup, with the property being stubbed with a fake StreamedFile = filename => new MemoryStream(). So if you’re looking for a way to test streams with .NET, this is a way around the limitations of the framework.

[sourcecode language=”csharp”]
public class with_a_compliance_report_job
{
protected static ITradeRepository tradeRepository;
protected static IFileSystem fileSys;
protected static ComplianceReportingJob job;

Establish context = () =>
{
tradeRepository = Substitute.For<ITradeRepository>();
fileSys = Substitute.For<IFileSystem>();

reportContent = FizzWare.NBuilder.Builder<TradeComplianceViewModel>.CreateListOfSize(10).Build().ToList();

tradeRepository.GetComplianceReport().Returns(reportContent);
fileSys.DirectoryExists(string.Empty).ReturnsForAnyArgs(true);

job = new ComplianceReportingJob(tradeRepository, fileSys)
{StreamedFile = filename => new MemoryStream()};
};

protected static List<TradeComplianceViewModel> reportContent;
}
[/sourcecode]

This is a pretty sweet solution, for now. The ideal solution however, would be that Microsoft fixes the framework, which is very unlikely to happen. The whole closed, sealed, and otherwise locked up framework stack is a massive problem with testability. Which then directly impacts maintainability and other things over time.

Shout it