Development Experience(s)

In our last installment , we discovered how to start unit testing our Azure Functions, looking at the HTTP Trigger (and evaulating the function's HTTP response). This time, we'll take a look at using the QueueTrigger, getting supporting data from table storage and outputting Blobs. Yup, I'm tossing you into the deep end! What are we trying to accomplish? This time, we will test a function that performs some arbitrary business logic on bank accounts. The function responds to a storage queue request, logs each command and ensures that each received command is executed exactly once. Almost like a real-world function, huh? ;-) In the function above, we are introduced to three types that we need to deal with in our unit tests - the IQueryable interface, IAsyncCollector and the CloudBlockBlob concrete type. IQueryable is easy enough to work with: Introducing the Testable Async Collector When I first started exploring this topic, I figured I could just use my favourit

You know ... I told myself to stay away from pre-releases and only stick to released software from now on. Well, I failed. Having great experiences from Azure Web Jobs , which I've written about before , I just had  to get my hands on the new Visual Studio tooling for Azure Functions, where you use the same tried and true attributes on your method arguments to bind to external resources as you've been accustomed to. Intellisense is awesome. Visual Studio is awesome. I'm really liking Microsoft these days! Now, one thing that was missing from any guidance that I could get my hands on, were how to properly test your functions. There are guides on how to write code and use tools to call your actual  functions in a host , but I couldn't readily find anything that told me how to test them quickly in isolation. Here's what I did: I created a new Unit Test Project, installed ... ... and ended up creating two constructs that turned out to be helpful: The Ver