Hi, currently writing a book on the subject and I'm doing a bit of research myself. There are two aspects of testing that you need to discern: the development

Hi, currently writing a book on the subject and I'm doing a bit of research myself. There are two aspects of testing that you need to discern: the development and the project management point of view. The first regards what and how to test things. This can be achieved by any developer and is moderately easy with the right help and mentoring. The second instead is the most difficult: trying to force tests in a non-test-focused environment, where the business does not understand the meaning and/or the value of testing can be poisonous to us and the business itself. In other words there must be an effort in both directions. I can keep talking about these two points, but I'll skip them for now unless you're interested. Regardless of the current environment you're in, and taking for granted that the second part is - if not fully, at least partially satisfied, let's have a look at how to start with TDD: the major problem you're facing is that TDD does not define "what to test". That's why BDD was introduced, to fill in the gaps that TDD has. Still BDD is somewhat lacking depth and proactive understanding from the project level on how much should be spent on unit tests, how much on functional and acceptance tests. On this note, Google has defined the ACC, which helps you define the testing plan for your application; I think it's totally worth from both a developer and business perspective to dig a bit more into that, especially if you want to get into testing properly. If you still fail to see why tests are important, let's put it down this way, using James Whittaker's words: "although it is true that quality cannot be tested in, it's equally evident that without testing is impossible to develop anything of quality". my 2 cents