The exception does not get tested.

It would be helpful to inform the user on the appropriate values to populate the dictionary with in the instructions. Took me a while to find this out.

While this is a good learning Kata for C#, throwing an InvalidOperationException for a missing key is not best practice.

From Microsoft C# docs:

InvalidOperationException is used in cases when the failure to invoke a method is caused by reasons other than invalid arguments. Typically, it is thrown when the state of an object cannot support the method call.

The hint in the starter code suggests using a dictionary as the underlying data structure. A dictionary would throw a "KeyNotFoundException" if the key isn't null and dictionary is not referenced with the TryGetValue method.

I'd suggest changing that test case to accept KeyNotFoundException as well.

• public Customer Customer returns a reference to the Customer if one is present or throws an InvalidOperationException with the message of "No customer present. Please consider calling 'HasCustomer' to check for presence first" if not.

The exception message is not tested.

The kata's proposed design for such a Option type is nonsense:

• Why inherit from IEnumerable? What IEnumerable means is that this Optional type can have 0 to many values. So the problem is not resolved at all, in fact it's even worse (it was 0 or 1 before).
• Similarly, why IEnumerable<Customer>? Why not make it a generic type? Why is it named Kata and not something more meaningful (like IMaybe)?
• The interface for obtaining the value is also nonsense because it does not distinguish between the concept of plain value and a collection of values. Why does it provide both .Customer and .GetEnumerator()? It cannot be both a plain value or a collection of values at the same time: if it's a plain value you need to lift it to get a collection, if it's a collection you need to Find/First from it to get a plain value.
• As mentioned below, the standard way to handle this in C# is null-conditional operators.

Initial code namespace should be MaybeKata, not MaybeKata.Incomplete.

Demonstrating Option type in C# is a poor choice because it's not the C# standard practice: the standard practice is to use the null-conditional operators instead.

The kata should be re-written in a language where such type exists and are used extensively as standard practice.

In functional programs these structures are often called "Options", in other languages they are often called "Maybe"s.

I think it's the opposite. At least in Haskell it's called Maybe, while in Scala it's called Option and in Java it's called Optional.

As the kata currently stands it's completely pointless because the tests are not leveraging the benefit of the refactoring.

The point of turning Status into a class is that anyone can add new Statuses from their side and the code will still work automatically with no changes to Kata class itself required. The tests or the description did not demonstrate any of this. So whatever learning value this kata might have it's whooshed from us; instead what we get is "refactor this way because I said so".

Also, why check if there's a _status field? It's also pointless.

Where are the random tests?

Test checking is woefully weak that nothing is enforced.

using System; is missing in initial code.

Initial code does not compile and gives tons of errors. If we're refactoring code I'd expect us to begin with code that can be run:

setup.cs(1,23): error CS0101: The namespace `global::' already contains a definition for `Status'
code.cs(1,17): (Location of the symbol related to previous error)

setup.cs(3,35): error CS0246: The type or namespace name `IVisitor' could not be found. Are you missing an assembly reference?

Your tests are too weak.

Expected and actual values are flipped.