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
In our early development of the MVP, we had limited context on how to structure our code to accommodate implementation details of FIT, GPX, and TCX. As a result, we went through many trials and errors. Introducing unit tests early on would have slowed down our ability to freely restructure the code.
However, to ensure the correctness of the program, we need to have proper unit tests to have more confidence in delivering high-quality code. Now that we have more confidence in our current code structure, introducing unit tests would be a good option to start. This proposal would serve as guidance on how the unit tests would be delivered, even though we still have no concrete timeline on how to fully deliver it.
The unit-tests will be divided into two parts:
The WebAssembly part (Golang)
The Frontend part (Vue-Typescript)
To start, for each part, covering all the happy path scenarios would be sufficient. Later, we can aim for at least 80% code coverage. Given that the core engine is written in Go WebAssembly, it's preferable to prioritize the WebAssembly part first.. However, we welcome anyone who wants to contribute by adding unit-tests either for the WebAssembly part or Frontend part.
Technical Difficulties:
Some code might be written in a way that makes it impossible to test, so some refactoring might be needed.
The text was updated successfully, but these errors were encountered:
Background
In our early development of the MVP, we had limited context on how to structure our code to accommodate implementation details of FIT, GPX, and TCX. As a result, we went through many trials and errors. Introducing unit tests early on would have slowed down our ability to freely restructure the code.
However, to ensure the correctness of the program, we need to have proper unit tests to have more confidence in delivering high-quality code. Now that we have more confidence in our current code structure, introducing unit tests would be a good option to start. This proposal would serve as guidance on how the unit tests would be delivered, even though we still have no concrete timeline on how to fully deliver it.
The unit-tests will be divided into two parts:
Golang
)Vue-Typescript
)To start, for each part, covering all the happy path scenarios would be sufficient. Later, we can aim for at least 80% code coverage. Given that the core engine is written in Go WebAssembly, it's preferable to prioritize the WebAssembly part first.. However, we welcome anyone who wants to contribute by adding unit-tests either for the WebAssembly part or Frontend part.
Technical Difficulties:
The text was updated successfully, but these errors were encountered: