- Each option has a set of values, which come from the app state
- Options also each have a config, which are defined in
configs.js
(potentially a large list, with 'dynamic' data-like variations)
We're testing the summarise
function. To isolate my tests, I've mocked the option configs. This means we don't have to couple the test to certain option configs, which allows an author to change the settings (e.g. option names) freely.
My tests work, but I feel it has a few issues:
- I can't directly spy on a config object, so I've exported a function
getOptionConfig()
which I can spy on. I feel like it would be cleaner to avoid an API; and just spy on the object if possible. - I feel it'd be much cleaner to pass the
_optionConfigs
object tosummarise()
(to avoid mocks completely). However, this would only pass the same issue to any functions which callsummarise()
. - Because I'm forcing a return value in the spies, I'm not testing the parameter that I'm passing to
getOptionConfig()
. Is this bad?
I'm quite new to testing, so I'm potentially going about this incorrectly. Can anyone shed any light on how they'd tackle this global "static-yet-dynamic" config data in their tests?