https://tech.uvoo.io/index.php?action=history&feed=atom&title=Test-plan 2026-04-05T17:50:38Z Revision history for this page on the wiki MediaWiki 1.35.2 https://tech.uvoo.io/index.php?title=Test-plan&diff=103&oldid=prev 2019-01-14T22:56:54Z

<p>Created page with &quot;# Test Plan What is the purpose of testing? 1. to ensure high quality code 2. to find and eliminate bugs This test plan is designed to accomplish those goals. ## Principle:...&quot;</p> <p><b>New page</b></p><div># Test Plan<br /> <br /> What is the purpose of testing?<br /> 1. to ensure high quality code<br /> 2. to find and eliminate bugs<br /> <br /> This test plan is designed to accomplish those goals.<br /> <br /> ## Principle: Write Tests For things that Make sense <br /> <br /> Testing works well for certain components and doesn't work so well for others. Most tutorials focus on pure functions with simple input and output, and ignore more complex state problems.<br /> <br /> The ideal testing situation is for a function or program which must handle a wide variety of inputs, such as a parser, or compiler. In these cases the quality of the program can be greatly improved by regularly running against a large data set.<br /> <br /> ### Guideline<br /> <br /> - Create tests for all tools that follow a unix stdin stdout pattern. We expect these tools to be the foundation of our project.<br /> - Create tests for pure functions.<br /> - Do not unit test trivial state changes.<br /> - Document the purpose of a test. If the test does not have a clear purpose it probably is just affirming the developer's original assumptions.<br /> <br /> ## Principle: KISS<br /> <br /> A lot of time can be spent fiddling with test frameworks. Tests also increase the amount of time to adapt to new business logic.<br /> <br /> ### Guideline<br /> <br /> - Avoid using a large testing library. Prefer simple functions.<br /> - Avoid complex mock scaffoldings.<br /> - Use assertions heavily directly in the code.<br /> <br /> ## Principle: Prefer Correctness<br /> <br /> &gt; Program testing can be used to show the presence of bugs, but never to show their absence - Dijsktra<br /> <br /> Tests can only identify bugs for particular inputs, while a proof can very for the correctness for all inputs. When possible prefer to verify correctness.<br /> <br /> A good example, was Alpheus and Justin working on the panel sizing system. They framed the problem mathematically and proved a valid solution. This mathematical notation was documented in the code, and was used to write several other helpful functions using the same ideas.<br /> <br /> ### Guideline<br /> <br /> - Describe problems in mathematical language when possible. (This usually simplifies the code and the problem.)<br /> - Prove algorithms mathematically and document them in the code, using latex syntax.<br /> - Identify and document invariants with assertions.<br /> <br /> <br /> # References<br /> <br /> https://medium.com/welldone-software/an-overview-of-javascript-testing-in-2018-f68950900bc3<br /> <br /> https://philipwalton.com/articles/how-to-unit-test-private-functions-in-javascript/<br /> <br /> https://medium.freecodecamp.org/learnbydiy-how-to-create-a-javascript-unit-testing-framework-from-scratch-c94e0ba1c57a<br /> <br /> http://wiki.c2.com/?ShouldUnitTestsTestInternalFunctions</div>

imported>Justin