As I am looking for a things to do, which helps me to get acquainted with the code, I have been looking at some GH issues mentioning testing (as that is partly my background as Engineering and Test manager). So I have a few questions as I don’t see (or found) anything documented.
Considering a development environment (no docker):
What checks are always taken (or ideally should be taken)?
Which checks should be done but are not or are lagging behind?
Like: “Always run Rubocop”. “Follow up with RSpec scenario X and Y”, “If possible run Z and etc…”
As a newbie on the project I miss information on clear steps (expected) to execute.
I noticed several testing related issues which are still open.
I also noticed PR’s which do not pass the checks (some seem environment related). What is the expected workflow for those?
Thanks for your message, and great to see you’re getting started on Foodsoft development!
Ultimately, these questions are for the current development team to answer. But I can chime in on some things I know. First, look at the Github Workflows, which will tell you the things that are run for each PR, which should all pass. These contain both rubucop, and rspec (including unit and integration tests, and more). Note that test coverage is not 100% (see coveralls, if that is still working). Also, plugins can alter the behaviour, and not all plugins are enabled by default (see Gemfile). So there are things that need to be manually tested, but that is a bit vague - the person working on a feature, would be expected to also test it in practice, and see if all seems well.
This project could actually use some thinking on what contributors can expect: is there a time where feedback can be expected? What do we do with old PRs? Will issues/PRs be closed after a time with no activity?
The answer to this has been, practically: just look at what is there. And as developer time comes and goes (most developers have time in batches over the years), any effort is welcome. For small PRs where there clarity on how we want it implemented, these can be merged quickly (I would think). For larger PRs, and if there is discussion on whether it is a good thing or not, I suppose this is a bit of luck, and try to get attention now and then.
Making this clearer would help (new) contributors, to my mind. In any case, you might consider open PRs as suggestions that need someone to look at it for a next step. In some cases, this could be closing (“this is very unlikely to be a fit contribution”), in other cases bringing it up-to-date, or doing some final improvements.
Hope this helps a bit of background on how this project (used to) work(s).
Since it affects a lot of files, it doesn’t really make sense to start anything else before this is merged, otherwise we’d have merge conflicts and it would take even more effort.
We’re hoping some people with good knowledge of the code base will review the PR.
