diff options
1 files changed, 19 insertions, 0 deletions
diff --git a/doc/ b/doc/
index fb7e56a..06aa446 100644
--- a/doc/
+++ b/doc/
@@ -33,6 +33,25 @@ The linear search will on average require checking `n/2` neighborhoods, where `n
Since it forms the basis of the other approaches, this is the method currently implemented in `neighborhoods`.
In the discussion section, I mention a method for reducing this number with preprocessing.
+## Testing
+`neighborhoods` was developed following test driven development, so growing the testing suite was crucial to success.
+There are three main sections of the testing code: computational geometry internals, neighborhood processing, and the interface between the two.
+The computational geometry internals are tested with a few examples for each function with a mix between positive and negative expected results.
+The interface is tested by creating a polygon with specific features (concave and convex corners), choosing points by hand that correspond to interesting locations (where interesting is defined as 'potential trouble for the geometry').
+A graphical representation of the polygon and test points is provided below.
+Red points are outside and green are inside.
+A [gnuplot]( script is provided to regenerate the image if different data points are desired.
+The data is stored in [test/data](../test/data) and is accessed by both the testing framework and the plotting script.
+![polygon test](example_polygon.png)
+Processing of the neighborhood data is handled by running the entire program with the filenames for the Grand Rapids data as parameters (just as it would be called from the command line).
+The output is captured with my favorite Clojure function to date, `with-out-str`, and compared against expected results.
+These three groups of tests cover the ['happy path']( through `neighborhoods`.
## Discussion
There are many options for improving the performance of the approach implemented in neighborhoods.