Investigate coupling between some test fixtures

While making some changes to turn things into generics, I ran into a strange case where, simply by calling the new generic ViewFactory.Create<T>() method, in the AddViewOperationsTests test methods, instead of the existing ViewFactory.Create(Type t) method, caused some tests in ColorSchemeTests to always fail (something caused the color schemes themselves to not be handled as expected, without a change to the related tests), and certain tests in AddViewOperationsTests itself to also fail inconsistently.

I believe the problem is likely in the tests themselves, though there is also the potential of an underlying problem in TGD. Either way, I'm going to dive into it and see what's going on.

I have not yet begun actual investigation into the code, beyond where and what caused the initial breakage of the tests (and then rolled back those changes, until this is resolved). So, what follows is just some initial speculation, partially to put my thoughts down as a guide for myself:

My first suspicion (again, no investigation has started yet) is that there is a direct code dependency between those two classes, at minimum. I have this suspicion because the tests in ColorSchemeTests fail, with the change made in AddViewOperationsTests, even if ONLY the ColorSchemeTests fixture is run, by itself, for even just a single case of it. So, unless a smoking gun makes itself obvious right away, this is probably the first avenue I'll explore.

Another potential case is that it could be related to the Tests.RoundTrip static helper method which, itself, has quite a lot of dependencies both internal to and external to TGD and its test project. There's a chance that that method may be the source of at least part of the issue, as the problems manifested on Labels, and that method both hard-codes Labels and is used by nearly every test method in nearly every test fixture, as a handy and clever helper to greatly simplify round-tripping created views to code and back, usually at the beginning of most tests (and this is also where the only useable part of the stack trace ended, when the tests failed, so it is on the short list of suspects).

Another potential case is related to the base Tests class, but it is something that deserves its own issue, regardless of what happens in this one. That'll be the next issue I post, shortly.

dodexahedron / TerminalGuiDesigner

Investigate coupling between some test fixtures #29