If you’ve been following this series you’ll know that in part 2 we covered using AutoFixture to create anonymous data four our tests. In this article we will take another look at some of the unit tests in our project and see how we can use AutoFixture to create complex types.

In my previous article I setup a fictitious project to demonstrate how brittle unit tests can create a burden on developers as they implement applications and take time to refactor their codebase. This is the complete opposite of what you want and need from unit tests, it’s vital that unit tests are there to help you refactor with confidence, rather than discourage you from refactoring.

In this second article I am going to demonstrate how the tests we wrote can be rewritten to use AutoFixture and anonymous data.

Have your unit tests become a ball & chain?

Are small changes in your application breaking all of your unit tests?

Thinking about scrapping unit tests completely ?

In this blog series I’ll show some problems in the way unit tests are often written, and how you can take advantage of AutoFixture to help you get back to having unit tests that are a benefit instead of a burden. My goal is that by the end of the series you will a good understanding of AutoFixture and its benefits, and that you will feel confident enough to use it in your own projects.

In my previous post I described how I put together some C# AWS Lambda functions with a shared Onion architecture behind them. This was my first attempt at using AWS Lambda and I feel like my solution worked well for me but with the potential downside that each new AWS Lambda function required a new C# project.

In this follow on post I am going to address this issue by using a single project which contains multiple Lambda functions.

In this post I’m going to try and document my experience of learning AWS Lambda with C# and applying Onion Architecture to my .net solution.

Although I have used Onion Architecture many times on my types of project I have never written any AWS Lambda before and I had never seen any examples where this architecture is used. Most examples of Lambda seem to be just ‘Hello World’, so I decided to try it out myself and create this post to document it. Because I’m new to AWS, a seasoned practitioner might find some room for improvement in some of the things I’ve done.

This is just a quick post to demonstrate a technique for replacing branching code (if-else and switch statements), and replacing it with a look-up. Sometimes by eliminating branching logic this can make your application easier to comprehend (which means more maintainable).

By the end of the article you should feel quite comfortable in using the technique yourself.

If you’re writing unit tests you’ll probably have heard the debate about whether or not you should use mock objects.

Or maybe you’re struggling with difficult to write or maintain tests because they’re complex?

In this article I’m going to attempt to show that you need both techniques in your solutions and show how understanding when to use each style of test will help you on your TDD and DDD journey.