> On Aug 7, 2018, at 10:56 AM, Alexis King <lexi.lam...@gmail.com> wrote:
>
> I guess I’ll take the bait and give the obvious-but-unhelpful answer,
> “Don’t use global variables.” :)
>
> I’m joking, but only just barely. It seems difficult to give concrete
> advice without knowing more details about your program and why you felt
> it was necessary to use global mutable state in the first place, so
> absent some reason why you need them, I have to recommend you just
> refactor your code to eliminate the globals. The standard techniques for
> writing testable code in other languages still apply in Racket, most
> notably dependency injection (aka “passing arguments to functions”).
> Racket also provides a few tools of its own for managing that kind of
> dynamic parameterization, such as parameters and units.
>
> Theoretically, an alternative solution would be to create a separate
> namespace (via racket/sandbox or otherwise) for each test file, allowing
> each test to use its own instantiation of the library. This almost
> certainly isn’t what you actually want, though, since real (non-test)
> clients of your library will bump into the same problem, and expecting
> them to do the same workaround is unreasonable. Indeed, I think the
> difficulty of testing an API like this means the the test suite is doing
> what it probably should: hinting that your API is hard to work with and
> needs to be changed.
>
> Alexis
After some preliminary testing it looks like Racket’s parameter is exactly what
I need!
Thanks!
Kevin
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
