From fbd07da05a71d6d8b710c3554a68ae6ebb2b0aa9 Mon Sep 17 00:00:00 2001 From: Sean Leary Date: Wed, 6 May 2015 14:37:52 -0500 Subject: [PATCH] Update README.md --- README.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index f92e029..d91f7c2 100644 --- a/README.md +++ b/README.md @@ -20,7 +20,13 @@ The fundamental issues with JSON-Java testing are: * JSONObjects are unordered, making simple string comparison ineffective. * Comparisons via **equals()** is not currently supported. Neither JSONArray nor JSONObject overrride hashCode() or equals(), so comparison defaults to the Object equals(), which is not useful. * Access to the JSONArray and JSONObject internal containers for comparison is not currently available. -* JSONObject sometimes wraps entries in quotes, other times does not, complicating comparisons. + +General issues with unit testing are: +* Just writing tests to make coverage goals tends to result in poor tests. +* Unit tests are a form of documentation - how a given method actually works is demonstrated by the test. So for a code reviewer or future developer looking at code a good test helps explain how a function is supposed to work according to the original author. This can be difficult if you are not the original developer. +* It is difficult to evaluate unit tests in a vacuum. You also need to see the code being tested to understand if a test is good. +* Without unit tests it is hard to feel confident about the quality of the code, especially when fixing bugs or refactoring. Good tests prevents regressions and keeps the intent of the code correct. +* If you have unit test results along with pull requests, the reviewer has an easier time understanding your code and determining if the it works as intended. When you start working on a test, add the empty file to the repository and update the readme, so that others will know that test is taken.