Increase unit test coverage

qcif / data-curator

Data Curator - share usable open data

MIT License

265 stars 38 forks source link

Increase unit test coverage #283

Closed Stephen-Gates closed 6 years ago

Stephen-Gates commented 6 years ago

To increase confidence in making code changes and to encourage other code contributors, significantly increase unit test coverage to that it is clear if a code change has broken any existing functionality.

Stephen-Gates commented 6 years ago

Include one end-to-end test

Stephen-Gates commented 6 years ago

Show before and after code coverage

Stephen-Gates commented 6 years ago

@impl tag being used to indicate which tests have been implemented

Stephen-Gates commented 6 years ago

@mattRedBox what changes are needed for https://github.com/ODIQueensland/data-curator#tests ?

GitHub
ODIQueensland/data-curator
data-curator - Data Curator - share usable open data

ghost commented 6 years ago

@Stephen-Gates I've updated the README.md Note: Spent time on acceptance test boilerplate, rather than unit test Note: haven't put in relish step or put into CI yet. But, have added what I need to get me through main process interaction for now (including context menu, Application menu and dialog interactions). Will merge dependabot PRs and upgrade electron to latest 8 with next dev version (just to ensure this release stability).

Stephen-Gates commented 6 years ago

Thanks Matt Do you want me to create an issue for the above in v0.12.0?

ghost commented 6 years ago

No need - it's a BAU task which is always on my plate.

ghost commented 6 years ago

Just as a reference: Part of issue with spectron and main process (ie: serialisation):

https://github.com/electron/spectron/issues/21 The library we use to mock the dialogs (effectively intercept, close and return value): spectron-fake-dialog With more exploration, better ideas may emerge, but this library and the way it handles main code - as we want to make sure we don't test any of the core main functionality itself (ie: we want to be sure the actions occur e.g,., a menu item has been clicked, a dialog box has opened, but we don't want to test any of the behaviours or properties of those actual main methods - that's the job of Electron developers and their testing processes), binding it's own 'stubbed' method in place of the actual main method, is useful, perhaps to duplicate for other main process stumbling blocks - and will get us through for now (until Spectron perhaps do more to take care of this side of things).

ghost commented 6 years ago

Just keeping open until we actually achieve signficant coverage

Stephen-Gates commented 6 years ago

See also https://github.com/ODIQueensland/data-curator/issues/594 as a way to publicly demonstrate coverage

louisjasek commented 6 years ago

@Stephen-Gates @mattRedBox has this issue been closed?

ghost commented 6 years ago

No - frameworks are setup, but coverage not where it could be/should be.