Interview with Egil Hansen

I started a new series in dotnet pro. Some of the interviews I want also to present here.

I am lucky enough to get to know outstanding people such as Egil Hansen. He is a great member of the C# / Dotnet community and very passionate about open-source. Since I started a new series in the German "dotnet pro" magazine about up-and-coming dotnet open-source project (i.e., hidden gems - projects should have less than 1k stars, but worth knowing) I thought his project "bUnit" fully qualifies. It is a testing framework for Blazor.

In the magazine the interview has been translated to German. I'll post the original below.

1. Can you tell me a bit about your background (e.g., current position)?

Egil Hansen: I started playing around with computers back in the 90’s when I got my first 386-based computer running at a whopping 16 MHz. I mostly played games and tinkered with DOS, didn’t really start programming seriously before much later. After realizing my pro-gamer career wasn’t going to turn into a real career in the early 2000’s – being one of the best Quake 3 1-on-1 players in Denmark didnt pay a lot at the time – I started studying computer science at university. End result was a master’s in software engineering from the IT University in Copenhagen, and a BA in computer science from the University of Copenhagen.

Now I am working as a Managing Architect in Netcompany ( and spending my spare time doing open source as much as possible.

2. Why did you start bUnit?

EH: After watching one of Steve Sandersons presentations on Blazor early 2019, I started playing around with it and began creating a Boostrap component library. As a big proponent of TDD, I quickly realized how hard it was to unit test components, let alone do TDD. Thus, bUnit came about my own need to do testing.

3. What other (open source) projects do you contribute to and why?

EH: Out of the need to create stable unit tests for Blazor with bUnit, I also created what has become AngleSharp Diffing. It provides you a way to semantically compare to HTML snippets to each other, which means tests won’t break, if the HTML produced by a Blazor component is still semantically the same as the expected HTML. That can potentially lead to much more stable tests, since changes to e.g. insignificant whitespace, which can occur easily if you reformat the code, doesn’t break the test.

4. What is your vision for bUnit?

EH: There are a few key features missing before bUnit can go out of beta.

  • Right now, it depends on xUnit, which it uses to run tests with, but I am working to make it agnostic to any of general-purpose test frameworks in .NET land (MSTest, Nunit, xUnit).
  • There is a special kind of tests in bUnit, called Razor-based tests, where you define your tests in Razor syntax instead of just pure C#, that you normally use in unit tests. It has a bunch of benefits, but also a lacks good integration with test runners. That would be nice to have a good solution for before v1 is done.
  • Improved performance would be nice. The Blazor renderer used by bUnit does have a startup cost with each test run, and it would be great if I can minimize that, to make tests run even faster.

In generally though, the goal or vision for bUnit is to enable its users to create stable and easily maintainable tests for their Blazor components. The API design philosophy is, to as much as possible, not surprise the users, and hopefully, land them in the pit of success.

5. What feature is from your perspective missing in C# / .NET?

EH: C# 8 was a huge step up for me with the new nullable feature which I use as much as possible, and I generally like the direction both C# and .NET are heading with .NET 5. It would be great if default interfaces became more powerful. I know it is a controversial opinion in some circles but having e.g. private fields and thus properties available as well, would allow for some interesting scenarios around composition. With Blazor component libraries, it could be used to add multiple independent cross-cutting traits to components, without having to duplicate code in each component.

I am also hopeful that record types make it into the next version of C#. It will make it easier to work with immutable data and use a more functional programming style.

Created .


Sharing is caring!