From d0dfb8863c92c09757fb6606402c2b8a451e2bd3 Mon Sep 17 00:00:00 2001 From: Neil Middleton Date: Wed, 25 Sep 2024 11:26:45 +0100 Subject: [PATCH] Lint fixes --- data/dashboard.yml | 2 +- source/manual/testing-policy.html.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/data/dashboard.yml b/data/dashboard.yml index 4ac9f66..ed70dd2 100644 --- a/data/dashboard.yml +++ b/data/dashboard.yml @@ -4,7 +4,7 @@ sites: - name: Get started developing on OTT url: /manual/get-started.html - - name: OTT Testing Policy + - name: OTT Test Policy url: /manual/testing-policy.html - name: Slack channels sites: diff --git a/source/manual/testing-policy.html.md b/source/manual/testing-policy.html.md index dcbbd93..461a987 100644 --- a/source/manual/testing-policy.html.md +++ b/source/manual/testing-policy.html.md @@ -1,6 +1,6 @@ --- owner_slack: "#ott-core" -title: Testing Policy +title: Test Policy section: Guide for new developers on OTT layout: manual_layout parent: Learning GOV.UK @@ -18,7 +18,7 @@ Well tested code is easier to maintain, easier to extend, and easier to deploy. * Core functionality that is critical to the system. We must know that once implemented, this functionality will continue to work as expected through later change and refactoring * Areas of doubt. If we are not 100% sure that a particular area of code is correct, we should test it to make sure we know that it is correct. - + > Adding tests for code we are confident in arguably adds technical debt to the codebase. These are tests that slow down the test suite for little benefit, and add brittleness to the codebase through change. Think carefully about whether this is a good trade-off before adding tests. ### What should we not test?