package_control_channel
package_control_channel copied to clipboard
wbond
Consider Cleaning up Tests with unittest_data
I just wrote https://github.com/wbond/unittest_data for data-provider driven tests.
While not 100% different from the current approach since it still generates test methods, it may produce code that is easier to follow.
I think I'd need the translated code in order to see if it's actually easier to read or not.
Just to be clear, this wasn't something for you to do @FichteFoll, but a note for myself once it is 2015 and I've finished some pressing other projects.
In the readme? Yes.
The main difference is that all "test running" functions of a kind are generated by the same function, which means we'd need to do a lot of data traversion (or regeneration since I suppose traversion is not possible) since the tests are in kind of related.
I mean, currently we can generate repository, package and release tests in the same procedure without any duplicated data but with your proposed module we'd need to split that up into three separate methods that all parse the repository data. To me, it seems like it would make things harder.
Yes, I would still like to look into it, however I still haven't finished those projects yet.
I think I'm about on a 9-month yak shaving expedition. :smile:
This is by now a really old idea. My personal experience is that 8 years ago I didn't have ideas that were as good as ones I've been having more recently.
For instance, IMO, tests here should focus on having the repository files match a schema. We're not responsible for the quality of the packages themselves. Taking on that responsibility even in a limited way has burned out all previous package reviewers. We do some checks, and that's fine.
So what kind of unit tests does what's essentially just a JSON file need? A schema check, maybe a formatter. Maybe you could typo-check labels if you find that really important. (Edit: And maybe maybe check if the package repo has any semver tags).
The entire world around running such tests has changed since this issue was initially filed. Let's close this for now until we A. feel a need for something and B. find that need important enough to actually do something about with (at that point) current technology.
