For testing (and development) purposes, we need a collection of test files with a good variation of:
- Main devices (i.e. the device or application that generated the FIT file)
- Sensor data (i.e. the type of data stored in the FIT file)
- Sports
- Metadata (structured workout, types of laps, etc.)
Preferably, test files are as small/short as possible to reduce the duration of running tests.
For sweatpy, I created a test file structure with an index to describe and keep track of test files: https://github.com/GoldenCheetah/sweatpy/blob/master/sweat/examples/index.yml. I would like to implement something like that again.
It would allow easy adding and keeping track of test files and could also allow marking some files as "slow" and for example only trigger those in the CI/CD test runs and not (by default) for local development.
We should look at the other FIT parse libraries, for inspiration but (if the license allows it) also as a source for various FIT files.
For testing (and development) purposes, we need a collection of test files with a good variation of:
Preferably, test files are as small/short as possible to reduce the duration of running tests.
For
sweatpy, I created a test file structure with an index to describe and keep track of test files: https://github.com/GoldenCheetah/sweatpy/blob/master/sweat/examples/index.yml. I would like to implement something like that again.It would allow easy adding and keeping track of test files and could also allow marking some files as "slow" and for example only trigger those in the CI/CD test runs and not (by default) for local development.
We should look at the other FIT parse libraries, for inspiration but (if the license allows it) also as a source for various FIT files.