20,741
edits
Software testing: Difference between revisions
Jump to navigation
Jump to search
→Why write unit tests?
| Line 50: | Line 50: | ||
The benefits of not just chasing clear "wins" are great: An awesome learning experience for new developers; the ability to catch latent, unreported bugs; making it easier to refactor current code by creating a safety net; making it easier for current developers to accept new contributions (when accompanied with passing tests); helping other test writers by contributing to the common test suite infrastructure; and being able to easily check for memory leaks or other issues via Valgrind.<ref>https://sourceforge.net/p/flightgear/mailman/message/36977686/</ref> | The benefits of not just chasing clear "wins" are great: An awesome learning experience for new developers; the ability to catch latent, unreported bugs; making it easier to refactor current code by creating a safety net; making it easier for current developers to accept new contributions (when accompanied with passing tests); helping other test writers by contributing to the common test suite infrastructure; and being able to easily check for memory leaks or other issues via Valgrind.<ref>https://sourceforge.net/p/flightgear/mailman/message/36977686/</ref> | ||
If you are a new | If you are a new developer, just jump in and write any test! It does not need to catch a bug. Do whatever how ever you wish! Just dive in this shallow end and you'll see that the water is not cold. | ||
Writing a test as a safety net. | Writing a test as a safety net. You write the test to pass, make your changes, then make sure that the test still passes. Then you push both the test and core changes.<ref>https://sourceforge.net/p/flightgear/mailman/message/36977465/</ref> | ||
=== Benefits of unit testing === | === Benefits of unit testing === | ||