From 1f7165de31d59d9f6388be20f3e48718f0e66a0c Mon Sep 17 00:00:00 2001 From: Bouwe Andela Date: Mon, 6 Nov 2023 14:39:15 +0100 Subject: [PATCH 1/2] Remove testing chapter --- _sidebar.md | 1 - best_practices/testing.md | 92 --------------------------------------- 2 files changed, 93 deletions(-) delete mode 100644 best_practices/testing.md diff --git a/_sidebar.md b/_sidebar.md index 66eec357..8358e8d6 100644 --- a/_sidebar.md +++ b/_sidebar.md @@ -5,7 +5,6 @@ * [Code Quality](/best_practices/code_quality.md) * [Code Review](/best_practices/code_review.md) * [Communication](/best_practices/communication.md) - * [Testing](/best_practices/testing.md) * [Releases](/best_practices/releases.md) * [Documentation](/best_practices/documentation.md) * [Standards](/best_practices/standards.md) diff --git a/best_practices/testing.md b/best_practices/testing.md deleted file mode 100644 index b74177fd..00000000 --- a/best_practices/testing.md +++ /dev/null @@ -1,92 +0,0 @@ -# Testing - -Writing tests takes time, so why should you do it? Tests save time later on, and increase the quality of the software. More specifically: - -* Makes you more confident that your software is correct. -* It saves time in finding bugs, the tests give an indication where the bug is. -* Makes it easier to make changes to the code, the tests will catch changes to way the software functions. -* Tests communicate how software is intended to function. - -These points do not apply to prototype / throwaway phase. - -## unit tests - -* [unit tests](https://en.wikipedia.org/wiki/Unit_testing) -* [Guide: Writing Testable Code](https://raw.githubusercontent.com/jptiancai/Guide-Writing-Testable-Code/master/Guide-Writing%20Testable%20Code.pdf) - -## Continuous integration - -To run testing, perform code quality analysis and build artifacts a Continuous Integration server can be used. The build will be performed every git push and pull request. Using a CI server will help with `it works for me` problems. -The Netherlands eScience Center uses continuous integration services as much as possible when creating code. - -[continuous integration](https://en.wikipedia.org/wiki/Continuous_integration) (CI) - -CI meaning: compile, unit test, integration test, quality analysis etc. -Once there is some build process established and tests set up, CI should be configured too. -It will save you a lot of time on debugging and allow for much quicker problem diagnosis. - -### Online services for continuous integration - -- [AppVeyor](https://www.appveyor.com/) -- [CircleCI](https://circleci.com/) -- [GitHub Actions](https://github.com/features/actions) -- [GitLab CI/CD](https://docs.gitlab.com/ee/ci/) - -The Netherlands eScience Center public repositories should be built with a -free public continous integration service. - -### Nightly builds - -Most CI builds are triggered by a git push, but sometimes the repository must be built every night. -Possible reasons for nightly builds: - -* Make sure the repository stays working even if there are no changes pushed to the repository, but it's dependencies are changing possibly breaking the code in the repository. -* The build performs an action that needs to be performed daily like updating a cache. - -For triggering nightly builds in GitHub Actions [Cron jobs](https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#onschedule) can be used. - -### Polling tools - -All major CI services support some form of cctray.xml feed. This feed can be read by polling tools to automatically keep an eye on your project builds. For instance, [BuildNotify](https://anaynayak.github.io/buildnotify/), [CCMenu](http://ccmenu.org/) and [CCTray](http://cruisecontrolnet.org/projects/ccnet/wiki/CCTray_Download_Plugin) give you a tray icon that turns red when a build fails. - -## Code coverage - -Code coverage is a measure which describes how much of the source code is exercised by the test suite. -At the Netherlands eScience Center we require minimum of 70% coverage. - -Setting up code coverage for a repository depends on the programming language, see the [language specific guides](language_guides/languages_overview.md) for setup instructions. - -The code coverage should be performed when a test suite is run as part of Continuous Integration build job. -The code coverage results can be published on code coverage and/or [code quality services](https://the-turing-way.netlify.app/reproducible-research/code-quality/code-quality-style.html#online-services-providing-software-quality-checks). - -### Code coverage services - -The publishing of the code coverage can be performed during a Continuous Integration build job. -The code coverage service offers a visualization of the coverage and a metric which can be displayed as a badge/shield icon on the repository website. -See the [language specific guides](language_guides/languages_overview.md) which code coverage services are available and preferred for that language. - -Code coverage services support many languages and a usually free for Open Source projects. -Below is a short list of services and their strengths. - -#### [Codecov](https://codecov.io) - -Shows unified coverage and separate coverage for [build matrix](https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix) e.g. different Python versions. -For example project see https://codecov.io/gh/xenon-middleware/xenon, with a Java 7/8 and Linux/Windows/OSX OS build matrix. - -#### [Coveralls](https://coveralls.io) - -More popular then Codecov. -For example project see https://coveralls.io/r/NLeSC/MAGMa - -## End2end tests - -For (web) user interfaces. [example with protractor and angular](https://angular.github.io/protractor/#/) - -Once the web page has any interface, e2e tests should be implemented. - -## Dependencies tracking - -[Dependabot](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/about-dependabot-version-updates) or other service depending on codebase language. - -Checking for dependency updates should be done regularly. It can save a lot of time, -avoiding code dependent on deprecated functionality. From 817bc8b304b0aacffd31e36472b2ae7047312721 Mon Sep 17 00:00:00 2001 From: Bouwe Andela Date: Wed, 8 Nov 2023 16:28:18 +0100 Subject: [PATCH 2/2] Fix links --- best_practices/documentation.md | 2 +- best_practices/language_guides/python.md | 6 +++--- best_practices/language_guides/r.md | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/best_practices/documentation.md b/best_practices/documentation.md index 7d3c5822..f5c73e15 100644 --- a/best_practices/documentation.md +++ b/best_practices/documentation.md @@ -87,7 +87,7 @@ developer and contributor since things have to be explained only once. A good CO file describes at least how to perform the following tasks: * How to [install the dependencies](#documented-development-setup) -* How to run [(unit) tests](testing.md#unit-tests) +* How to run [(unit) tests](https://the-turing-way.netlify.app/reproducible-research/testing/testing-unittest) * What [code style](https://the-turing-way.netlify.app/reproducible-research/code-quality/code-quality-style.html) to use * Reference to [code of conduct](#code-of-conduct) * When using a [git branching model](version_control.md#choose-one-branching-model), the choice of branching model diff --git a/best_practices/language_guides/python.md b/best_practices/language_guides/python.md index ecf2e54b..f08f0167 100644 --- a/best_practices/language_guides/python.md +++ b/best_practices/language_guides/python.md @@ -173,13 +173,13 @@ The development environment will typically accumulate (old) packages during deve ### Code coverage When you have tests it is also a good to see which source code is exercised by the test suite. -[Code coverage](../testing.md#Code_Coverage) can be measured with the [coverage](https://coverage.readthedocs.io) Python package. +[Code coverage](https://the-turing-way.netlify.app/reproducible-research/testing/testing-guidance#aim-to-have-a-good-code-coverage) can be measured with the [coverage](https://coverage.readthedocs.io) Python package. The coverage package can also generate html reports which show which line was covered. Most test runners have have the coverage package integrated. -The code coverage reports can be published online in code quality service or code coverage services. +The code coverage reports can be published online using a code quality service or code coverage services. Preferred is to use one of the code quality service which also handles code coverage listed [below](#Code_quality_analysis_tools_and_services). -If this is not possible or does not fit then use one of the generic code coverage service list in the [software guide](../testing.md#Code_coverage_services). +If this is not possible or does not fit then use a generic code coverage service such as [Codecov](https://about.codecov.io/) or [Coveralls](https://coveralls.io/). ## Code quality analysis tools and services diff --git a/best_practices/language_guides/r.md b/best_practices/language_guides/r.md index a8ab8c7b..e2627f04 100644 --- a/best_practices/language_guides/r.md +++ b/best_practices/language_guides/r.md @@ -127,7 +127,7 @@ R function documentation offers plenty of space to document the functionality, i See also [checking](http://r-pkgs.had.co.nz/check.html) and [testing](http://r-pkgs.had.co.nz/tests.html) R packages. note that within RStudio R package check and R package test can be done via simple toolbar clicks. ### Continuous integration -Continuous integration should be done with an [online service](../testing.md#Online-services-for-continuous-integration), see [Chapter](../testing.md) on testing. +[Continuous integration](https://the-turing-way.netlify.app/reproducible-research/ci) should be done with an online service. ### Debugging and Profiling Debugging is possible in RStudio, see [link](https://support.rstudio.com/hc/en-us/articles/205612627-Debugging-with-RStudio). For profiling tips see [link](http://adv-r.had.co.nz/Profiling.html)