I'll try to asnwer the last quesiton which is:

GameStatus and GameStatusStrict classes seem to be simple enough so as not to need unit testing. Do you agree?

Nope. Here's an example why:

public static bool operator ==(GameStatusStrict arg1, GameStatusStrict arg2) =>

    ReferenceEquals(arg1, null) ? ReferenceEquals(arg2, null) : arg1.Equals(arg2);

This is wrong because it returns true if either object is null. It should be

public static bool operator ==(GameStatusStrict arg1, GameStatusStrict arg2) =>
    !ReferenceEquals(arg1, null) &&
    !ReferenceEquals(arg2, null) &&
    arg1.Equals(arg2);

and another one:

public bool Equals(GameStatus gs) {
    return gs != null ?
        (IsOver == gs.IsOver) && (IsTie == gs.IsTie) && (Winner == gs.Winner) :
        false;
}

This one isn't wrong but it's not some simple logic either. One ! in the wrong place and it doesn't work anymore. A unit test should verify this works as expected.

Actually you can simplify this one too. You don't need the ternary operators here because you can just chain the experssions with &&

public bool Equals(GameStatusStrict gs) =>
    gs != null &&
    _isOver == gs._isOver &&
    _isTie == gs._isTie && 
    _winner == gs._winner;

One more example why you should test it... because you already do it with

static class Checker {
    public static void Check(string varName, bool value, bool expectedValue) {
        if (value != expectedValue)
            throw new InvalidOperationException(string.Format("{0} should be {1}.", varName, expectedValue));
    }
}

It's so simple that you don't trust yourself and check the values anyway :-)

I'll try to asnwer the last quesiton which is:

GameStatus and GameStatusStrict classes seem to be simple enough so as not to need unit testing. Do you agree?

Nope, I don't because you can easily make mistakes in code that is too obvious to test it. Here are a few examples:

public static bool operator ==(GameStatusStrict arg1, GameStatusStrict arg2) =>

    ReferenceEquals(arg1, null) ? ReferenceEquals(arg2, null) : arg1.Equals(arg2);

This is wrong because it returns true if either object is null. It should return true only if both objects are really equal:

public static bool operator ==(GameStatusStrict arg1, GameStatusStrict arg2) =>
    !ReferenceEquals(arg1, null) &&
    !ReferenceEquals(arg2, null) &&
    arg1.Equals(arg2);

Also in this method there is enough room for making things not working correctly:

public bool Equals(GameStatus gs) {
    return gs != null ?
        (IsOver == gs.IsOver) && (IsTie == gs.IsTie) && (Winner == gs.Winner) :
        false;
}

This one isn't wrong per se but it's not any simple logic either. One ! in the wrong place and it doesn't work anymore. A unit test should verify this works as expected.

Actually you can simplify this one too. You don't need the ternary operators here because you can just chain the experssions with &&

public bool Equals(GameStatusStrict gs) =>
    gs != null &&
    _isOver == gs._isOver &&
    _isTie == gs._isTie && 
    _winner == gs._winner;

One more example why you should test it... because you already do it with

static class Checker {
    public static void Check(string varName, bool value, bool expectedValue) {
        if (value != expectedValue)
            throw new InvalidOperationException(string.Format("{0} should be {1}.", varName, expectedValue));
    }
}

It's so simple that you apparently don't trust yourself already and check the values anyway.

I'll try to asnwer the last quesiton which is:

GameStatus and GameStatusStrict classes seem to be simple enough so as not to need unit testing. Do you agree?

Nope. Here's an example why:

public static bool operator ==(GameStatusStrict arg1, GameStatusStrict arg2) =>

    ReferenceEquals(arg1, null) ? ReferenceEquals(arg2, null) : arg1.Equals(arg2);

This is wrong because it returns true if either object is null. It should be

public static bool operator ==(GameStatusStrict arg1, GameStatusStrict arg2) =>
    !ReferenceEquals(arg1, null) &&
    !ReferenceEquals(arg2, null) &&
    arg1.Equals(arg2);

and another one:

public bool Equals(GameStatus gs) {
    return gs != null ?
        (IsOver == gs.IsOver) && (IsTie == gs.IsTie) && (Winner == gs.Winner) :
        false;
}

This one isn't wrong but it's not some simple logic either. One ! in the wrong place and it doesn't work anymore. A unit test should verify this works as expected.

One more example why you should test it... because you already do it with

static class Checker {
    public static void Check(string varName, bool value, bool expectedValue) {
        if (value != expectedValue)
            throw new InvalidOperationException(string.Format("{0} should be {1}.", varName, expectedValue));
    }
}

It's so simple that you don't trust yourself and check the values anyway :-)

I'll try to asnwer the last quesiton which is:

GameStatus and GameStatusStrict classes seem to be simple enough so as not to need unit testing. Do you agree?

Nope. Here's an example why:

public static bool operator ==(GameStatusStrict arg1, GameStatusStrict arg2) =>

    ReferenceEquals(arg1, null) ? ReferenceEquals(arg2, null) : arg1.Equals(arg2);

This is wrong because it returns true if either object is null. It should be

public static bool operator ==(GameStatusStrict arg1, GameStatusStrict arg2) =>
    !ReferenceEquals(arg1, null) &&
    !ReferenceEquals(arg2, null) &&
    arg1.Equals(arg2);

and another one:

public bool Equals(GameStatus gs) {
    return gs != null ?
        (IsOver == gs.IsOver) && (IsTie == gs.IsTie) && (Winner == gs.Winner) :
        false;
}

This one isn't wrong but it's not some simple logic either. One ! in the wrong place and it doesn't work anymore. A unit test should verify this works as expected.

Actually you can simplify this one too. You don't need the ternary operators here because you can just chain the experssions with &&

public bool Equals(GameStatusStrict gs) =>
    gs != null &&
    _isOver == gs._isOver &&
    _isTie == gs._isTie && 
    _winner == gs._winner;

One more example why you should test it... because you already do it with

static class Checker {
    public static void Check(string varName, bool value, bool expectedValue) {
        if (value != expectedValue)
            throw new InvalidOperationException(string.Format("{0} should be {1}.", varName, expectedValue));
    }
}

It's so simple that you don't trust yourself and check the values anyway :-)