Resolution for 2018: get back into the habit of reading blog posts and articles about testing. Starting today!
writing documentation for code
This makes some interesting points: (1) Naming practices are your first line of documentation (I knew that). (2) Code comments that explain why something is being done are more likely to be useful than comments explaining what the code is doing. Usually the code itself is its own best explanation of “what”, unless the code is doing something obscure such as using an interface that is poorly or incorrectly documented. I think that’s a good guideline, although, thinking about test case automation, I think that may have more need for “what” type comments. If you have cause to assume that the maintenance on automated tests is likely to be done by junior people with limited understanding of both the product and the feature that just changed, then some code that is self-documenting for author-level experience may need explaining, and you may need comments to tie pieces of code back to test case steps – although possibly those could be considered as “why” type comments. (3) Unit tests are excellent documentation. I never thought of it that way, but Yes!