PandaMagnus
commented
5 years ago Maybe an AddTestCaseDependency set of methods, and an AddTestBlockDependency set of methods?
I think for a short term fix I'll instantiate the logger in the test setup, add it to the ServiceContainer as a singleton instance (which there is already a method for) and then do the setup/teardown logging I need.
Another potential short term fix I'll investigate if I have time is to add a AddLogger<TService, TImplementation> method that adds the logger as a singleton so I can build some of the logging back down into TestBuilder so it comes "for free". This consideration probably makes this related to issue IntelliTect/TestTools.TestFramework#10
Using this at a client now, and immediately ran into an issue with trying to set up a logger implementation... I have no way to add it at a level that can exist outside of a test block. If I add a AddTestCaseDependency method, I feel like that falls into inconsistent naming since the other methods are AddDependencyService and AddDependencyInstance.
Long story short, we need a way to help guide people into the correct scope without being confusing. I'm hesitant to open up a way to have free access to the ServiceContainer since we (generally) only have a limited subset of scopes and services that we want to deal with when executing a test case, and we want to avoid accidentally giving someone the ability to get into funky situations (re-instantiating Selenium every time, or not invoking a factory correct, or etc.)