AllenInstitute / AllenInstitute/MIES
Hardware Tests: Allow to use different headstages and channel numbers to catch bugs
Nobody has claimed this yet.
- Dominant language
- IGOR Pro
- Stars
- 30
- Forks
- 11
- Avg merge
- 1d 40m
- Merged PRs (30d)
- 8
Description
#868 is a good example of a bug which was not caught in CI testing. The reason is that the code mixed up active channel count and channel number. But for our current setup (HS0, DA0, AD0) this always coincides.
We want to have an easy way to run the tests for different HS/DA/AD. One challenge is that the test assertions assume HS0. And we want to have a succinct and short way to test for other combinations.
Look into doing that first for UTF_AnalysisFunctionManagement.ipf as test ballon.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with UTF_AnalysisFunctionManagement.ipf and inspect how the hardware test assertions assume HS0 and how active channel counts are handled. Run the existing tests, then define a concise way to exercise different HS/DA/AD combinations. Done means the tests cover differing headstages and channel numbers and can catch count-versus-number mixups.
Written by the indexing model from the issue text.
Assessment
- Domain
- embedded-iot, testing-qa
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100