One of my teammates has an AWESOME response to testing and here it is: "The point of writing tests is to know when you are done. You don't have to write failin

One of my teammates has an AWESOME response to testing and here it is: "The point of writing tests is to know when you are done. You don't have to write failing tests first if you are just trying to figure out how to implement something or even fix something. You must write a failing test before you change prod code. How do you do square this seeming circle? - Figure out what you need to do - Write tests - Take your code out and add back in in chunks until your tests pass - Got code left over? You need to write more tests or you have code you don't need Without the tests, you cannot know when you are done. The point of the failing test is that it is the proof that your code does not do what you need it to do. Writing tests doesn't have to slow down the software development process. There are patterns for various domains of code (e.g., controller layer, service layer, DAO layer). To do testing efficiently, you need to learn the patterns. Then when you need to write a new test, you identify and follow the pattern. You also need to use the proper tools. If you're using Java or Kotlin, then you MUST use PIT (http://pitest.org http://pitest.org). It is a game changer for showing you what parts of your code are untested." - Steven, Senior Software Engineer on our team