Many developers see the value in getting started with testing their
web
applications, but don’t know how to actually start using it. I’ll write
about a variety of products and processes which cover the whole range of
testing web applications. The posts in this series will be published in
the coming weeks. You can find a rough table of contents below but the
list may get modified or extended.
Approach
Initially you must spend some thoughts on how you want to approach testing. The main obstacle is that almost always you start with an existing project that already has a big code base. It seems impossible to ever get enough testing in place to be meaningful. But my experience shows that even very little coverage can already improve quality of your system a lot.
I recommend to enforce two very simple rules:
- No bugfix without a test.
- Develop new features using the test-driven methodology.
But whatever happens, don’t go and try to implement 100% code coverage for your legacy code. That will kill you - and drive motivation down very quickly.
Implementing a test for each bugfix is very little work. To fix the bug, you have to reproduce the problem anyway. During that process you will find at least one test case that can be implemented in an automated fashion relatively easy.
The first few tests will be the hardest. But don’t be discouraged by that, it will get easier. It’s hard mainly for two reasons. First and most important, testing is something you have to learn. You didn’t learn your programming language in just a few minutes either. Second a lot of software is not written with testability in mind.
I hope this series will help you getting better with both these aspects.
Table of Contents
This table of contents will get updated when I write the articles. Keep coming back to it.
- Introduction
- Testing framework
- Unit testing
- Functional testing
- JavaScript testing
- Continuous integration
- Test-driven development
- Testability
- Measuring coverage