Eliminate global state #5634
Unanswered
pepicrft
asked this question in
Contributions
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Context
Through recent work with Elixir, I learned to appreciate the impact that having a non-mutable global state has on the quality of a test suite. We've done pretty decently with Tuist, but there are some areas where we leaned too heavily on reducing language verbosity at the cost of introducing the following complications in our test suite:
Environment.shared
. Because of it, tests that want to change the configuration, end up with asetenv
here and there, mutating a global state that other tests might be depending on.There are other utilities, like the
FileHandler
, that is also accessed globally viaFileHandler.shared
, but hold no state and we've been doing great with the pattern of scoping tests to a temporary directory, so we don't have to worry much about it.Proposal
We need to do something about it to ensure our test suite remains healthy, otherwise, the issues that we are already seeing will become more apparent. Here's my proposal
--verbose
and usingsetenv
to set the value to later access it as a global variable, we should pass it down. I'd take the opportunity to ensure we are always reading the values in the right order of priority (e.g. flags > environment variables > ...)logger
parameter. That way tests have control over that and can pass a mocked instance as needed that's scoped to the test being executed.The challenge lies in achieving the above without adding too much verbosity to our APIs. We could encapsulate everything that represents the "outside world" that Tuist can interact with in an interface and pass that one down, for example
context
(I'm open to suggestions regarding naming):Tests would then have functions to instantiate mocks. That way we don't have to resort to OOP, like we are currently doing with
UnitTest
andIntegrationTest
XCTest subclasses that represent different mocking behaviors. We could have one, and let developers control that on a per-test or per-tests-class basis.Beta Was this translation helpful? Give feedback.
All reactions