People can quibble about the definition of "unit" tests, but essentially, automated testing is an executable specification of your code's behavior. Let's say I

People can quibble about the definition of "unit" tests, but essentially, automated testing is an executable specification of your code's behavior. Let's say I write a piece of code to calculate a dollar value for an investment portfolio. Then, I want to validate it. I could poke at it and see how it behaves on some examples, but this would be a one-time thing. Better for me to write some tests which set up some sample data and assert that the code calculates the right results. Later on down the line, maybe I find a bug -- maybe it doesn't work right when you purchased a stock, then purchased some more of it. I could fix it, manually test it, and call it a day, but it would be better if I first expressed the bug as a unit test (i.e. I set up some data which causes the code to generate a result different from what I expected, and so the test fails), and then fix the code. Since I also have my original test cases, I can be sure that I didn't break some other behavior when fixing this bug. Similar reasoning applies to adding functionality -- leave the old tests intact and add new tests. Tests are not about configuration. It may use the word "test" but "test whether XYZ is installed" is a different question from what unit tests are about. Tools which look for problems like XSS are not tests either. I don't know what to call them. They are a good idea. Selenium is a testing tool for validating web apps at the application level. Purists might call it a tool for functional or integration testing rather than unit testing.