Awkward Coder

Earlier this week I was trying to unit test an asynchronous service (Foo) which used another asynchronous service (Bar) internally and ran into an issue trying to mock out the Bar service so that it would cause the retry & timeout schedules to fire. Bar is defined as follows, the implementation is irrelevant as it being mocked for the tests: 1: public interface IBarService 2: { 3: IObservable<Unit> Generate(); 4: } Foo is similarly defined: 1: public interface IFooService 2: { 3: IObservable<Unit> Generate(); 4: } The implementation of the Foo service is the important part, it uses the Boo service to generate a value, it's expected to generate the value or Timeout, if it fails to generate a value (for what ever reason) it's expected to to Retry: 1: public class FooService : IFooService 2: { 3: private readonly IBarService _barService; 4: private r...

I realised this week I'm not being as functional when creating an Rx extension method as I should could be. This came out of a discussion I was having with @leeoades about a Pausable<T> extension we thought we needed at work. Lee had a solution and I thought I'd try to create one without looking for the answer on the t'internet. 1: public static IObservable<T> Pausable<T>( this IObservable<T> stream, IObservable< bool > paused, bool initialState = false ) 2: { 3: ... 4: } Hopefully the idea of the method is obvious - have the ability to pause & resume the publishing of instances to the stream. Before implementing Pausable<T> I thought I'd implement an extension that didn't remember state whilst paused - Suspendable<T>, as you can see the same signature. 1: public static IO...

When using WebAPI inside a test fixture make sure you shutdown the HttpSelfHostServer instance correctly or your tests will more than likely fail when run from a continuous testing framework like nCrunch. See this post for info about using the self hosting version of WebAPI inside a test fixture. So my tests were running successfully when run inside Visual Studio from either the inbuilt runner or via Reshaper, but were failing when run from nCrunch: The failing tests weren't consistent either, sometimes none would fail, sometimes a couple, sometimes all... What the tests had in common was they were using a shared resource setup inside the test fixture setup method - this is like the setup method for a test but scoped at the class (test fixture) level. The setup was failing randomly were it was setting up the WebAPI self host - see highlighted yellow area, you can see the failing icon for nCrunch at the side: The exception was telling me it was trying to crea...

If you've been doing Rx for a while it's very likely you're also be into testing with TDD. In which case you'll have come across testing observable timers but if not then what follows is how easy this is. So lets say I want to test the following method, it generates a 'tick' according to the time span parameter: 1: public IObservable<Unit> TickEvery(TimeSpan timeSpan) 2: { 3: return Observable.Interval(timeSpan).TimeInterval() 4: .Select(_ => new Unit()); 5: } When testing this I don't want to be dependent on the scheduler clock, what I mean is you don't want the test code to have to do some kind of 'wait' operation whilst the Observable.Interval is generating values. The answer is to use the Reactive Extensions Testing Library . It provides the TestScheduler  which allows to manipulate the underlying clock using the AdvanceBy & AdvanceTo methods which then means you can trigger any...