XS✔ ◾ CodeAuditor Scan - Fix tag names uppercase (SSWConsulting#6978)

* CodeAuditor Scan - Fix tag names uppercase CodeAuditor detected tag names in uppercase in latest scan. See https://codeauditor.com/htmlhint/fe7dd6bd-900d-480a-0df2-12cfff5af056 To comply with rule https://htmlhint.com/docs/user-guide/rules/tagname-lowercase * Update rule.md Hi @tombui99 FYI we should avoid `<br>` in Markdown. The way to create a line break is by adding 2 spaces after the 1st line --------- Co-authored-by: Tiago Araújo [SSW] <[email protected]>
Marxoz · Oct 12, 2023 · 125dbeb · 125dbeb
1 parent 1a2c02d
commit 125dbeb
Showing 1 changed file with 6 additions and 5 deletions.
diff --git a/rules/do-you-look-for-code-coverage/rule.md b/rules/do-you-look-for-code-coverage/rule.md
@@ -24,11 +24,12 @@ Code Coverage shows how much of your code is covered by tests and can be a usefu
 
 <!--endintro-->
 
-* You should focus more on the **quality** and less on the **quantity** of tests.
-* You should write tests for fragile code first and not waste time testing trivial methods.
-* Remember the 80-20 rule - very high test coverage is a noble goal, but there are diminishing returns.
-* If you're modifying code, write the test first, then change the code, then run the test to make sure it passes (aka [red-green-refactor](/make-sure-that-the-test-can-be-failed)).<BR>**Tip**: This is made very easy by the "Live Unit Testing" feature in Visual Studio - see [Do you use Live Unit Testing to see code coverage?](/use-live-unit-testing-to-see-code-coverage).
-* You should run your tests regularly (see [Do you follow a Test Driven Process?](/before-starting-do-you-follow-a-test-driven-process)) and, ideally, the tests will be part of your deployment pipeline.
+* You should focus more on the **quality** and less on the **quantity** of tests
+* You should write tests for fragile code first and not waste time testing trivial methods
+* Remember the 80-20 rule - very high test coverage is a noble goal, but there are diminishing returns
+* If you're modifying code, write the test first, then change the code, then run the test to make sure it passes (aka [red-green-refactor](/make-sure-that-the-test-can-be-failed)).   
+   **Tip**: This is made very easy by the "Live Unit Testing" feature in Visual Studio - see [Do you use Live Unit Testing to see code coverage?](/use-live-unit-testing-to-see-code-coverage)
+* You should run your tests regularly (see [Do you follow a Test Driven Process?](/before-starting-do-you-follow-a-test-driven-process)) and, ideally, the tests will be part of your deployment pipeline
 
 ![Figure: Code Coverage metrics in Visual Studio. This solution has high code coverage (around 80% on average)](CodeCoverage2010.png)