@@ -291,24 +291,25 @@ with those in two ways:
291291### Testing
292292
293293It should be possible to add tests incrementally as we develop
294−pretty-printing code and new issues are discovered. The logic is
295−straightforward:
294+pretty-printing code and new issues are discovered. For each Haskell
295+module that we want to test, we perform the following steps:
296296
297−1. Given input snippet of source code parse it and pretty print.
297+1. Given input snippet of source code parse it and pretty print it.
2982982. Parse the result of pretty-printing again and make sure that AST is the
299− same as AST of original snippet module span positions.
299+ same as AST of original snippet module span positions. We could make
300+ this part of a self-check in the formatter.
3003013. Check the output against expected output. Thus all tests should include
301302 two files: input and expected output.
3023034. Check that running the formatter on the output produces the same output
303304 again (the transformation is idempotent).
304−5. It's a good idea to steal test cases from test suites of existing
305− libraries like Brittany and Hindent.
306−6. After that we may add test cases for opened issues that Brittany and
307− Hindent have.
308−7. When we're confident enough we can start “mining” new issues by running
309− the program on real source code from Hackage till we don't get new issues
310− anymore. For every issue that we find this way a test case should be
311− added.
305+
306+In order to grow our testsuite, we would borrow test cases from test
307+suites of existing libraries like Brittany and Hindent.
308+Then we may add test cases for opened issues that Brittany and Hindent have.
309+
310+When we're confident enough, we can start “mining” new issues by running
311+the program on real source code from Hackage till we don't get new issues
312+anymore. For every issue that we find this way, a test case should be added.
312313
313314### Functionality of executable
314315