Proper way of accessing TestContext.WriteLine from classes outside TestClass?

Hello,

I am using MSTest with selenium to run web tests.

Web testing promotes the Page Object Model to model a web page, abstracting what the test does from how it is done and promoting re-usability.

When running test serially, we can make use of Console.WriteLine from a PageObject class to let the test writer know important information about the test like variable values used and test flow, however the same approach cannot be taken when running in parallel as Console.WriteLine is redirected to the first test running.

A solution to this would be to pass TestContext to the PageObject class but this means that PageObject classes which normally only use a WebDriver parameter in their constructor would have to be refactored.

Another problem that arises is that a reference to MSTest has to be added on the project containing the PageObject classes to make use of TestContext.

We could try to avoid logging from PageObject and doing it only from test but if we have 100 tests and all of them have to log in the same page one would be tempted to avoid logging in each test and have the PageObject log in method do it for us.

Having said that my question is this: is passing TestContext as an argument the proper way to have access to TestContext from classes outside the TestClass? Is there another way to achieve this?

Thanks for your time.

[martsve]

You probably have to refactor your PageObjects. You could get around it with a static/singleton logger that uses the last used TestContext (set in the test initialization), but that would “break” for multi-threaded tests.

You should probably create a Logger/LoggerInterface that takes TestContext as a constructor-parameter. The logger/Interface can then be set in the constructor of your PageObjects. That way, your PageObjects are not dependent on the TestContext, and doesn’t need to know how it logs the data.

[nohwnd]

I would do what @martsve suggests. Injecting an implementation of an interface into the SUT. That way the dependencies on test framework would stay in the test project.