Ability to override config

[mjmeintjes]

It would be useful to override the configuration when running checks, as I would like to run checks as part of a test suite. Maybe some kind of dynamic var that is nil by default but gets merged in inside the merge-config file?

[gnl]

I'll give this some thoughts, thanks! In the meantime you could set a different :external-config {:ghostwheel {...}} in your testing profile.

[gnl]

Also if possible please do let me know if that's not sufficient in your use case and why.

[mjmeintjes]

My use case was more for running tests in the same process, for when I'm developing. I must admit that I'm still not 100% clued in to how testing with spec/ghostwheel should be done, so I might have a suboptimal workflow or just missing something.

Basically, I use kaocha for running tests, and then when developing tests I just send the test to the repl using cider-eval-defun-at-point and kaocha.repl/run.

I wanted to have a test that does the ghostwheel checks by just calling ghostwheel.core/check inside the test. But to do that, I needed to override the config, as the project config is set up not to do extensive checks. I thought it would be possible to some type of dynamic binding to override the config, but looking at the code it doesn't seem possible,

[gnl]

This sounds like it should be a thing, coming with the next release. :)

[gnl]

As for the testing workflow, this part of the documentation talks about it a bit:
https://github.com/gnl/ghostwheel#performance-considerations-or-how-much-generative-testing-is-enough
The TL;DR is to have your number of tests as high as tolerable for your test suite and then also try putting (g/check) on the bottom of the namespaces you also want to test on hot reload with a small number of tests and see how that works for you.
As for running the tests with (g/check) – generally speaking that'd be the way to go, because it sets up the custom reporter and everything.

[gnl]

👋 Hi. I'm posting this same comment to all issue threads to just give a quick heads up that the project, despite rumours and some evidence to the contrary, is not dead. It was hibernating for a little while and now nearing the long-awaited next release, which will fix some long-standing issues (and introduce some breaking changes to the config).

I'll be reviewing all open issues and PRs over the next couple of weeks, so stay tuned and thanks for the patience.

See also this Slack thread

[gnl]

Project update July 2023: DO NOT PANIC – this is not a eulogy