Paul "Code Grump" Turner

Quite happy to proceed this way. As I said, my perspective has been influenced by trying to build something considerably more minimalist and leveraging test framework features. I appreciate you...

My thoughts on these questions. > 1. Should we have one generator for all test frameworks and no longer have test-framework packages? It's a big change, but it seems feasible....

Thanks for the input, everybody. > You are right that the integration tests (in our case the SystemTests) are harder to diagnose, but I see no other option to test...

Since I'm deep in all the test frameworks thanks to looking at code-generation, I think I should chip in here. The before-/after-feature hooks are definitely the most troublesome to get...

First of all, those are great finds. Good job on such thorough investigation. Onto the problem itself: ideally, a good API design prevents invalid states, but in this instance, I...

This seems like a reasonable way to leverage the MS Configuration components. It does unfortunately highlight the problem of having a "JSON" configuration type as we're loading that information from...

Does the extension have a good reason for needing to parse content itself? I expect we'll need to do some refactoring to providing configuration in a less-coupled way.

I have some challenges with the cognitive model we have here. First of all, it seems clear from [gasparnagy](https://github.com/gasparnagy)'s explanation that we're currently mixing a lot of configuration concepts into...

My thoughts right now (subject to change): - We should consider separating our design-time configuration (generation and tooling) from our runtime configuration entirely. Runtime is all about where the code...

My current focus is to get all test scenarios in the System tests to pass for MSTest, but I'm not able to decipher the test-failure for scenario. The output is...