DEV Community: Audrius Masiulionis

Why I built Flagsweep

Audrius Masiulionis — Mon, 28 Sep 2026 12:52:42 +0000

On 26 September I released the first version of Flagsweep, a free and open source tool for managing the feature flags a team keeps in Azure App Configuration. This post explains where the idea came from and why I think it's worth building.

What I kept seeing

I've spent ten years building and running .NET systems for banks, pension providers and energy companies. In that time I watched several teams struggle with their feature flags, and the trouble looked the same each time.

Clients sat down to test a feature and found it switched off in their environment. A flag would be on in staging and off in production, and nobody was sure why. Azure's revision history is no help there, because it doesn't record who made a change.

The people who most needed to switch flags were product owners and support. They couldn't make sense of the Azure portal, so they asked a developer every time.

No one owned the flags either. Once a rollout was done the flag stayed where it was, in the code and in the store, and the technical debt kept piling up.

The opportunity

Azure App Configuration does the runtime part well. It stores the flags, and the application reads them through Microsoft's feature management libraries. What it lacks is the part that concerns people: who is allowed to change a flag, who did change it, who owns it, and when it should go away.

The established feature flag platforms cover that, but they come with their own flag store and their own SDKs. A team that already runs on App Configuration would have to move its flags and change its applications to use one.

I saw room for something smaller: leave Azure in charge of the runtime and add the missing layer on top. With Flagsweep the flags stay in Azure, and applications keep reading them with the SDKs they already use. Flagsweep writes to the same store and leaves any feature filters and variants set in the portal as they are.

I used the FeatureOps manifesto as the checklist for what that layer should contain.

What the first release does

I tried to answer each of those problems directly.

The flag list shows every flag as one row with its state in each environment, and marks the flags that are switched differently between environments. Anyone on the team can check what is on where before a test session starts.

People are invited by link and don't need access to the Azure account. There are two roles, admin and member. An environment such as production can be protected, so that only admins change flags there.

Every change goes into an audit trail with who made it, in which environment, when, and the old and new values. Changes made outside Flagsweep, in the portal, the CLI or a pipeline, are marked as out of sync.

Every flag has an owner and a retire-by date, which is 90 days out unless you mark the flag permanent. Overdue flags get a badge, so the stale ones are easy to find.

What I left out

This release handles boolean flags on Azure only. I had built multi-variant flags and AWS AppConfig support, and I removed both before the release. I wanted the first version to do one thing on one provider.

Flagsweep is self-hosted. It ships as one Docker image and keeps its data in a SQLite file, so the connection string to your store stays on your own infrastructure.

The licence is Apache-2.0. I chose it so that a company's open source policy doesn't stop anyone from installing it.

Building it alone

I built most of Flagsweep while working full time as a contract principal engineer. I finished it while I was between jobs.

What comes next

AWS AppConfig is next. After that I plan an Enterprise edition with approval workflows, single sign-on, drift alerts and CI integrations.

I don't know yet whether other teams feel this pain as strongly as the ones I worked with, and I'd like to find out before I build more. If your team keeps flags in a cloud store, tell me which one you use, roughly how many flags and environments you have, and what happens today when a flag goes stale.

The site and docs are at flagsweep.com, the code is on GitHub, and questions and ideas go in Discussions.

A better way to verify Mocks (XUnit, Moq, .NET)

Audrius Masiulionis — Sun, 13 Feb 2022 09:55:55 +0000

When I started practicing TDD writing unit tests became my everyday routine. Over my professional career, I've picked up a few techniques that help write tests more cleanly and verify all of the code dependencies. I use XUnit test framework for writing tests and Moq Nuget package to mock code dependencies. I've noticed that most developers are not familiar with good mock verification techniques, which I will cover in this post.

In this post, I will not cover the benefits of unit testing like better code quality, executable documentation, or ease of executing complex business scenarios swiftly. I find unit testing in most cases beneficial and even mandatory.

Sample Code

To start unit testing some code is needed. I've created a simple class with a single method. Class's method contains logic to create a new order.

public class OrderService
{
    private readonly IItemRepository _itemRepository;
    private readonly IOrderRepository _orderRepository;

    public OrderService(
        IItemRepository itemRepository, 
        IOrderRepository orderRepository)
    {
        _itemRepository = itemRepository;
        _orderRepository = orderRepository;
    }

    public async Task CreateAsync(int itemId, int itemQuantity)
    {
        var item = await _itemRepository.GetAsync(itemId);
        if (item.Stock < itemQuantity) 
            throw new Exception($"Item id=[{itemId}] has not enough stock for order.");

        Order order = new()
        {
            ItemId = item.Id,
            Quantity = itemQuantity
        };

        await _orderRepository.CreateAsync(order);
    }
}

Let's assume that this retrieves data from a database. Those dependencies are abstracted in repositories. Abstracted dependencies are mandatory for mocking in unit testing.

Testing the code

I like to start with a happy path unit test. But first, let's begin with some test boilerplate code.

public class OrderServiceTests
{
    private readonly OrderService _sut;
    private readonly Mock<IItemRepository> _itemRepositoryMock;
    private readonly Mock<IOrderRepository> _orderRepositoryMock;

    public OrderServiceTests()
    {
        _itemRepositoryMock = new Mock<IItemRepository>();
        _orderRepositoryMock = new Mock<IOrderRepository>();
        _sut = new OrderService(
            _itemRepositoryMock.Object, 
            _orderRepositoryMock.Object);
    }

    [Fact]
    public void CreateAsync_ShouldCreateNewOrder()
    {
        Assert.False(true);
    }
}

If the code is building successfully and we are getting a failed test result we are all set. The next step is to implement the happy path unit test.

[Fact]
    public async Task CreateAsync_ShouldCreateNewOrder()
    {
        const int itemId = 1;
        const int quantity = 2;
        const int existingItemStock = 3;

        _itemRepositoryMock.Setup(m => m.GetAsync(It.Is<int>(i => i == itemId)))
            .ReturnsAsync(() => new Item
            {
                Id = itemId,
                Stock = existingItemStock
            });

        await _sut.CreateAsync(itemId, quantity);

        _itemRepositoryMock.Verify(m => m.GetAsync(itemId));
    }

Let's break down this test. I am using AAA(Arrange, Act, Assert) pattern for all my unit tests. This is an industry-standard and is a clean way to structure tests.

In the "arrange" part we specify what parameters are being used and set up the mock's method result after call.
In the "act" part we call the method that is being tested.
In the "assert" part mock calls are verified that has been set up. I am not using Asserts because my method doesn't return a value.

Although this test passed, it has a problem. I didn't verify if await _orderRepository.CreateAsync(order);. And I didn't setup _orderRepositry mock. This is caused by Moq default mock behavior. When you create a mock the behavior is set to Default. How this is performed can be viewed in Moq's source code:

/// <summary>
///   Initializes an instance of the mock with <see cref="MockBehavior.Default"/> behavior.
/// </summary>
/// <example>
///   <code>
///     var mock = new Mock<IFormatProvider>;();
///   </code>
/// </example>
public Mock(): this(MockBehavior.Default)
{
}

MockBehavior is an enum that specifies your created mocks behavior. Available values and behaviors are:

Strict: an exception is thrown whenever a method or property is invoked without matching configuration.
Loose: Moq accepts all invocations and attempts to create a valid return value.
Default: same as Loose.

By default Moq allows to create unit tests without forcing declaring every expected call. This can speed up test development, but I believe this is a bad practice. Developers must own responsibility for their code and every change they make to the code. This can be ensured by setting MockBehavior strict. This will require to set mock invocations.

 public OrderServiceTests()
    {
        _itemRepositoryMock = new Mock<IItemRepository>(MockBehavior.Strict);
        _orderRepositoryMock = new Mock<IOrderRepository>(MockBehavior.Strict);
        _sut = new OrderService(_itemRepositoryMock.Object, _orderRepositoryMock.Object);
    }

If mock invocation isn't set up exception is trhowned with following message:

Moq.MockException
IOrderRepository.CreateAsync(Order) invocation failed with mock behavior Strict.
All invocations on the mock must have a corresponding setup.
....

To fix the test we need to add the setup for IOrderRepository.

[Fact]
    public async Task CreateAsync_ShouldCreateNewOrder()
    {
        const int itemId = 1;
        const int quantity = 2;
        const int existingItemStock = 3;

        _itemRepositoryMock.Setup(m => m.GetAsync(It.Is<int>(i => i == itemId)))
            .ReturnsAsync(() => new Item
            {
                Id = itemId,
                Stock = existingItemStock
            });

        _orderRepositoryMock.Setup(m => m.CreateAsync(It.IsAny<Order>())).Returns(Task.CompletedTask);

        await _sut.CreateAsync(itemId, quantity);

        _itemRepositoryMock.Verify(m => m.GetAsync(itemId));
        _orderRepositoryMock.Verify(m => m.CreateAsync(It.IsAny<Order>()));
    }

After these fixes you can see that we are introducing more verification code. If you have multiple setups all the verifications must be performed. If your code is more complex and has multiple method calls this introduces complexity and trivial code which can be avoided. This can be achieved with MockRepository class which is helps mock instance creation and management. This class helps to create and verify mocks in one place.

public class OrderServiceTests
{
    private readonly OrderService _sut;
    private readonly MockRepository _mockRepository;
    private readonly Mock<IItemRepository> _itemRepositoryMock;
    private readonly Mock<IOrderRepository> _orderRepositoryMock;

    public OrderServiceTests()
    {
        _mockRepository = new MockRepository(MockBehavior.Strict);
        _itemRepositoryMock = _mockRepository.Create<IItemRepository>();
        _orderRepositoryMock = _mockRepository.Create<IOrderRepository>();
        _sut = new OrderService(_itemRepositoryMock.Object, _orderRepositoryMock.Object);
    }

Using MockRepository we set same mock behavior and we can verify all calls using VerifyAll() method;

 [Fact]
    public async Task CreateAsync_ShouldCreateNewOrder()
    {
        //test code

        //_itemRepositoryMock.Verify(m => m.GetAsync(itemId));
        //_orderRepositoryMock.Verify(m => m.CreateAsync(It.IsAny<Order>()));
        _mockRepository.VerifyAll();
    }

To take a step further we can use Dispose() method to verify mocks. Dispose() using XUnit runs after each test, so we can verify all mocks that have been setup and avoid _mockRepository.VerifyAll() code line in each test method.

public class OrderServiceTests : IDisposable
{
    private readonly OrderService _sut;
    private readonly MockRepository _mockRepository;
    private readonly Mock<IItemRepository> _itemRepositoryMock;
    private readonly Mock<IOrderRepository> _orderRepositoryMock;

    public OrderServiceTests(){...}

    [Fact]
    public async Task CreateAsync_ShouldCreateNewOrder(){...}

    public void Dispose()
    {
        _mockRepository.VerifyAll();
    }
}

This way we have a neat way to verify mocks and keep the test code cleaner.

Full code can be found here.
More on Moq can be found here.