You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The gist of these policies is that code should be open by default, and it should be open whether or not the code follows all the best practice (like having tests). Someone who wrote the Goldacre review said to me that code should be published even if it is bad. In fact, the policies even suggest coding in the open (from the start having your code be open source) as the ideal.
For this reason, it would be better if the quality framework changed some of its requirements from "required minimums" to "nice to haves" - or maybe it should even delete those requirements. This would mean this document aligns with what other government guidance suggests.
To be clear - I think you totally should have those tests, but that shouldn't be a requirement for open sourcing the code.
I tend to agree with this, but I think the better position would be to support projects to get a placeholder structure in place from the start with as little effort as possible. To meet AMBER the tests don't actually have to do anything - just having a make test:unit task that spits an UNIMPLEMENTED warning to the console would satisfy it, as currently written (which may not be intentional, but that's what I see). The advantage of doing it that way is that we can work towards having a common interface across projects, incrementally; it's aligned with nhs-england-tools/repository-template#76 and would be something I could PR into the Makefile...
The one place I personally don't think we should flex is the secret scanning, and I'm a little surprised that's AMBER rather than GREEN.
I still think that to say "you have to have tests to publish, but look we made it easy" is not the correct tack to take.
For instance, if a person is asking themselves "can I publish code in this repository we already have?" then they might think "no I can't" based on this guidance - and the template is not useful because this is a repository they already have.
Activity
regularfry commentedon Jul 6, 2023
I tend to agree with this, but I think the better position would be to support projects to get a placeholder structure in place from the start with as little effort as possible. To meet
AMBERthe tests don't actually have to do anything - just having amake test:unittask that spits anUNIMPLEMENTEDwarning to the console would satisfy it, as currently written (which may not be intentional, but that's what I see). The advantage of doing it that way is that we can work towards having a common interface across projects, incrementally; it's aligned with nhs-england-tools/repository-template#76 and would be something I could PR into the Makefile...The one place I personally don't think we should flex is the secret scanning, and I'm a little surprised that's
AMBERrather thanGREEN.Add a basic test infrastructure (#86)
adam-carruthers commentedon Jul 27, 2023
I still think that to say "you have to have tests to publish, but look we made it easy" is not the correct tack to take.
For instance, if a person is asking themselves "can I publish code in this repository we already have?" then they might think "no I can't" based on this guidance - and the template is not useful because this is a repository they already have.
Central government guidance from 2017 https://www.gov.uk/government/publications/open-source-guidance/when-code-should-be-open-or-closed suggests that person should definitely say "yes I can" and even "yes I should".