Update bugs.md

docs/bugs.md

@@ -1,11 +1,10 @@
 # Filing bugs
 
-[target package]: /api/internal/target
-[example of a target test]: /api/internal/target/baseandoverlaysmall_test.go
+[krusty package]: /api/krusty
+[reusable custom transformer test]: /api/krusty/customconfigreusable_test.go
 
-File issues as desired, but
-if you've found a problem with how
-`kustomize build` works, consider the
+File issues as desired, but if you've found a problem
+with how `kustomize build` works, consider the
 following to improve response time.
 
 ## A good report specifies
@@ -17,33 +16,37 @@ following to improve response time.
 
 ## A great report is a bug reproduction test
 
-kustomize has a simple test harness in the
-[target package] for specifying a kustomization's
-input and the expected output.
+kustomize has a simple test harness in the [krusty
+package] for specifying a kustomization's input and the
+expected output.
 
-See this [example of a target test], and contribution
-[#971](/../../pull/971),
-which does exactly the right thing.
+Copy one of those tests, e.g. this [reusable custom
+transformer test], to a new test file (with a new
+`foo_test.go` name).
 
-The pattern is
- * call `NewKustTestHarness`
- * specify kustomization input data (resources,
-   patches, etc.) as inline strings,
- * call `makeKustTarget().MakeCustomizedResMap()`
- * compare the actual output to expected output
+Insert the inputs you want to use, and run it like
+you'd run the reusable custom transformer test:
 
-In a bug reproduction test, the expected output
-string initially contains the _wrong_ (unexpected)
-output, thus unambiguously reproducing the bug.
+```
+(cd api; go test -run TestReusableCustomTransformers ./krusty)
+```
 
-Nearby comments should explain what the output
-should be, and have a TODO pointing to the related
-issue.
+The output will demonstrate the bug or missing feature.
+
+Record this output in the test file in a call to
+`AssertActualEqualsExpected`, per all the other tests
+in the [krusty package].  This makes the test pass,
+albeit with output demonstrating behavior you
+presumably want to change.
+
+Send the new test in a PR, along with commentary (in
+the test) on what you'd prefer to see.
 
 The person who fixes the bug then has a clear bug
 reproduction and a test to modify when the bug is
 fixed.
 
-The bug reporter can then see the bug was fixed,
-and has permanent regression coverage to prevent
-its reintroduction.
+Any bug fix first requires a test demonstrating the bug
+(so we have permanent regression coverage), so if the
+_bug reporter_ does this, it saves time and avoids
+misunderstandings.