One of the most debated topics in software development is testing. There are a lot of different opinions about many aspects of software testing, from its role in the design process, to the execution frequency and codebase coverage. For example, in most of the agile methodologies, unit testing plays a primary role, but not all projects can follow a strict test-first process. We have to find the best trade-off between the development process principles and the stakeholder's environment.
Not every project is treated in the same way when we talk about software testing. From time to time, there are projects with a very low number of tests; not every part of the code base is covered by any kind of verification.
It happens, this is the real world, and it will continue to happen. However, this is not a healthy way to proceed. Basically, software testing is the proper way to prove that our solution:
Works as expected
Meets functional and nonfunctional requirements
Is free of defects
There are contracts that consider that a project has concluded only in the presence of the appropriate documentation showing the correct system operation. To reach this objective, we need a solid testing strategy; this means that we need to carefully choose the following:
The right testing levels (unit, integration, acceptance, and so on)
The right testing types (regression, acceptance, usability, security, and so on)
The right testing process (test first, waterfall, top-down, and so on)
The right testing tools (frameworks, third-party products, dedicated environments, and so on)
The right testing outputs/reports, depending on who will evaluate them
Every single topic in these bullet points carries years of professional experience; it's not easy and immediate to become an expert. I also have to say that not every project covers all the enlisted items because of budget, time, or team habits.
On the other hand, there are two main reasons that suggest introducing at least a basic testing coverage from the bottom:
Better design
To avoid regression errors
This is a minimal scenario, but it's important to define a starting point, and I think this is the best place to begin a journey that will lead to a new way to consider software development.
This starting point is called unit testing, the first level of software testing; it works directly on the code and is usually the easiest to set up and learn.
This kind of testing should never be absent in any software solution. There are plenty of frameworks and libraries for the most important programming languages and Integrated Development Environments (IDEs); not writing tests is just a matter of will.
This book talks about web application testing, but it's not intended to be an exhaustive reference for software testing; more of a short manual, so we need to focus on unit testing. However, it's very important to understand that you should consider this book in a broader context, a piece in the jigsaw.
In particular, this is not a book that talks about Test Driven Development (TDD). TDD is a design methodology that leverages unit testing as the primary working tool. It's quite common to use TDD and unit testing as synonyms, but this is not correct. You cannot practice TDD without unit testing, but you can write unit tests without TDD and improve your design anyway.
In this book, I'd like to show what you need to do to set up a proper testing environment for a web solution, not teach you how to design your applications. Software design is a question of professional experience and involves a lot of general development aspects not specifically related to web development. On the other hand, what you will learn in this book is strictly related to the web application scenario, because we will talk about technical details, frameworks, and libraries that you can only find in web development.
By the way, you are welcome to apply TDD in web development using what you find in these chapters.