Joseph Musser

I'm not the person with that background and I'm hesitant to add something that we feel we can't change later, but I'm warming to elementwise for non-scalar types. I'm pretty...

Today you could write this: ```diff Assert.That(actualType, Is.EqualTo(expectedType), "Type"); +if (actualType != expectedType) return; foreach (var property in expectedType.GetProperties()) { /// } ``` ~~With this proposal, you would then have...

I agree that this is worth thinking about. If there is a formatter directly registered for a type, for instance `List`, then we should use that formatter rather than our...

What's the viability of a separate `[ExcludeValues(...)]` attribute? Maybe the framework could then delete test cases generated by any other parameter attribute.

I have a poor memory at times. I remember a general principle though that has come up in several discussions, which is that it's likely an antipattern for the tests...

@dcreel101 Reading your background info: would it work to use TestCaseSource or your own `ITestCaseBuilder` which returns instances of `new TestCaseData(args).SetCategory("cat1").SetCategory("cat2")` etc? Then the `--where` filter can test against the...

> Then I could generate my own test cases all the time using the CombinatorialAttribute (or any detected CombiningStrategyAttribute) like DefaultTestCaseBuilder does now. It would give me the chance to...

Yes, which assumption is fragile and needed in this scenario? We should address that.

@mikkelbu To test time, I'd try to be as integration-like as possible. The thing we have to keep in mind is that the test needs to be resilient in the...

> There is no natural type for list construction in .Net, because we have a rich set of well supported collection types. Not yet, but I think there's a good...