Adds unit test for improver.api

[MoseleyS]

While reviewing @cpelley's changes for DAG-runner, I found that this API lookup didn't have a unit test to prove that all the targets actually point to a usable object. This could result in unexpected behaviour. I've added a simple test that passes if each item points to an object that is callable.

Testing:

• Ran tests and they passed OK

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.34%. Comparing base (84a8944) to head (a2db8fc).
Report is 28 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2032      +/-   ##
==========================================
- Coverage   98.39%   98.34%   -0.05%     
==========================================
  Files         124      132       +8     
  Lines       12212    12820     +608     
==========================================
+ Hits        12016    12608     +592     
- Misses        196      212      +16     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[cpelley]

Fantastic. Thanks for filling this hole in the testing ❤️

[cpelley]

FYI, I have been considering adding CLI name alias support to the improver.api too. This would mean that peoples configurations can reference the same CLI name when accessing the plugin. Let me know what you think.

[MoseleyS]

FYI, I have been considering adding CLI name alias support to the improver.api too. This would mean that peoples configurations can reference the same CLI name when accessing the plugin. Let me know what you think.

This risks perpetuating names that we'd rather retire. On the other hand, in the future, we may want to change the name of a plugin without significantly changing the capability, so mapping would allow backward compatibility. That's a bit inconclusive...

[cpelley]

FYI, I have been considering adding CLI name alias support to the improver.api too. This would mean that peoples configurations can reference the same CLI name when accessing the plugin. Let me know what you think.

This risks perpetuating names that we'd rather retire. On the other hand, in the future, we may want to change the name of a plugin without significantly changing the capability, so mapping would allow backward compatibility. That's a bit inconclusive...

I do agree. The other option is that we go with the CLI names for lookup only (detaching the plugin name from the API).
I don't think there is an obvious best choice, so perhaps we stick with what we have 🤷‍♂️