This is so incredibly important. So many people do not spend time upfront getting projects structured and setup for builds, testing, deployment and the appropriate automation for each. I should not be copying and pasting out of date scripts from random folders on a network share to build. Or to package something. Or grabbing an EXE from one place and a DLL from another to run my unit tests.
People don't like writing tests because it's not as fun as writing code, but because it also requires a different setup, configuration and flow to get them executing. Figuring that out and making it easy to execute those tests is important in getting people to want to write them.
> Figuring that out and making it easy to execute
> those tests is important in getting people to
> want to write them.
This is so incredibly important. Anyone on your team should be able to run the test suite from the command line by invoking a single command. The easier and the quicker a test suite runs, the more people will run it.
Also, spending a day to setup a CI server (Jenkins, circleci.com or similar) is a good use of your time. You want to have the CI run the test suite after every commit to your mainline branches in SCM.
Another key aspect to testing is generating clear and concise error output. One thing I find very frustrating is when a CI build fails, but it is not clear why. I find most CI systems are very good at listing all the passing tests, or when a few tests fail in the expected way. When tests fail hard (exceptions thrown, processing not start or not running) I find that I often need to go reading through build logs to find out what went wrong and why.
People don't like writing tests because it's not as fun as writing code, but because it also requires a different setup, configuration and flow to get them executing. Figuring that out and making it easy to execute those tests is important in getting people to want to write them.