Unit

ZeUnit Testing Framework

From unit to comprehensive end-to-end testing and everything in between. ZeUnit guarantees writing tests isn't a bottleneck.

Birdseye ViewView on GitHub
ZeUnitTest.cs
public class SimpleSuite
 {
     public Fact GetExpectedValue()
     {   
         var actual = GetSomeString();    
         return actual == "expected";
     }
 }

What is ZeUnit?

ZeUnit is the vision of a unified mental model for testing, smoothing the difference between unit, integration and end-to-end tests with progression of progressive enhancement of extensable framework features. This unified approach not only simplifies the testing process but also fosters a consistent and cohesive testing strategy across your project.

Simple & Functional

ZeUnit embodies the ideals of functional programming, treating each test as a function that return a result. This approach ensures composability and seamlessly resuability as your project grows.

Scaling to Integration Testing

Armed with class composers and method binders ZeUnit scales to handling requirements of dependencies and testing data while keeping to the same consitent testing syntax.

Tailored Reporting

Visual stunning reports from ZeUnit provide early deliverables to stakeholders, allowing for low-effort user experience (UX) during greenfield project development.

Powerfully Adaptable

ZeUnit is readily extensible, allowing developers to tailor test code to a busiens domain with roll-your-own customizeable assertions, class composers, method binders and even test life-cycles.

Why ZeUnit?

ZeUnit was born from the frustrations with the existing integration test tooling. While the vast field of tools and framework offerings all very in the approach, a common theme across the frameworks is the inherent misunderstanding about the target audience of these tools.

The Flawed Assumption

Anyone besides software engineers will write integration/acceptance tests.

If only the markdown is simple enough, business people will metamorph in software engineers. The sales pitch for any individual integration frameworks always boils down to "Our markdown is simple enough!!!", but the harsh reality is that it is inevitably an engineer that write the tests. But now, handcuffed by the "simple" markdown instead of being empowered by general purpose language.

To walk back the combative connotation against business folk, the expectation that business people would write markdown ( a.k.a. "code" ) is outlandish! Business people don't write code, engineers write code, business people crete the data.

Its the Data not Tests

Data is the obvious handshake between engineers who write the tests and the business people who create requirements.

Now with that vision in mind, the idea behind ZeUnit began to hatch. Build an integration framework with out the 🥒 or other markdown files, and let dotnet developers do what they do best; write tests in C#.

Along the way experiments turned into proofs of concept, proofs of concept turned into working prototypes and those prototypes turned into ZeUnit. The result is a framework that tries to bring functional programming and element of composition to make testing more repeatable and easier to scale al the while keeping a *consistent mental model across all scales of testing.

Unit vs. Integration vs. End-to-End

How big is a unit test? How big is an integration test? How big is end-to-end or smoke tests? Probably all bigger than a breadbox, except maybe the unit test, they should be pretty damn small!

For the Tech-heads

Tired of all the "blah blah blah" and "philosophy" of testing? Need to get down to the nitty & gritty code?

  • Skip ahead to birdseye view and get a feeling for the different scale of testing with code examples.
  • Also see the getting-started guide to start writing your own ZeUnit tests in your projects.

The book How Google Tests Software talks about a system of test classification that doesn't neatly fit into the bucket of unit or integration testing. Google instead classifies their tests as small, medium or large. With that said when looking at the testing tools, there existing duality.

  • Unit Testing - in dotnet, this would be XUnit or NUnit, both of which focus on small scale testing and don't come with tools that enable contextual state.
  • Integration Testing - these would be your SpecFlow, Fitnesse and StoryTeller. At the abstract layer, these frameworks enable some kind of system state abstracted behind a fixture. These are the tools that sell the big lie of the "The Flawed Assumption".

But what if that distinction is less important than the weight it is given today. ZeUnit straddles the line between those worlds offering a simple syntax for writing pure unit tests and exposing a path of progressive enhancement that can scale test complexity and size. The goal is a single language across your entire test suite.

  • Is your test "Small"? It probably has no dependencies and lives inside a TransientSuite lifecycle. At this scale there might be value to extending the tests with some method binders to test reuse with method re-entry. The fakes-composer case-study offers helpful walk-through of the elements of class composition, which could be pushing the limits of the unit test breadbox.
  • For "Medium" size tests, parts of the system will need to be in-place for the tests to run correctly. This is where class composition really starts to shine. Composers built around the DI containers of choice can consume the same modules used by the application to create containers unique to the test.
  • Getting upt to "Large" tests? Test might need to execute as a specific chains of events and generate meaningful reporting data that shared with a larger audiences.

The simpler mental model comes down to composition of dependencies and a function that a Fact assertion no matter the scale of the test.

Next Section: Getting Started