1.3. Testing Myths
Some developers are required to explain every development practice and tool they'll need to create a piece of software to their managers; it's this manager who will then decide if the practice or tool is prudent for use. These managers are often developers that have been promoted, and their focus is no longer on development but managing. Former developers do not always make for the best managers; many times they don't keep their development skills sharp, and they can sometimes deny the use of new techniques and tools just because it's not the way that they do things. These situations do not make sense and are often hard for developers to handle, especially junior developers who are very eager to learn the latest and greatest technology.
Unit testing frameworks have been mainstream for roughly 10 years, but still, many managers fight developers who ask to implement unit testing frameworks. This section explores some of the popular myths around testing and helps give advice to the developer who is having issues implementing a testing regiment into their organization.
1.3.1. Testing Is Expensive
Frederick Brooks stated in his book of essays, The Mythical Man-Month, that "A bug found in the field can easily cost one thousand times more to resolve then one found in development."
If this is an argument that your manager uses, create a test to verify the functionality of the method that contains the bug and use it the next time the bug occurs — and time yourself. Then, write the fix for the bug and time yourself again. In most cases, you'll find that it only takes a few minutes to write a test for the functionality and now your argument to your manager can be, "If I was permitted to spend X amount of time creating a test, the customer would have never encountered this bug." Most managers will pay more attention to your requests if you have data to back up your reasons for wanting to do something.
If you continue on the path of creating tests for your system, over time you will form a comprehensive set of test cases. These test cases can then be executed during the development of your system, allowing you to catch regression bugs earlier in the process. By having the tests catch these bugs, you will save time and money in terms of re-testing the application but also in maintaining the system in production.
1.3.2. Only Junior Developers Should Create Tests
This claim is very far from the truth. It's important for junior developers to write tests along with senior developers. This claim is often an excuse for a manager to stick a junior developer on a project just to create a bunch of test plans. However, the test plans and automated testing a junior developer creates is often useless, because of a lack of training and guidance. It's important for senior developers to work closely with junior developers to teach them what makes good tests. Testing is easy; good testing is hard. It's difficult to learn how to write good tests and create test plans from books; books help with the concepts, but nothing matches sitting down and pair programming with an experienced developer for the day.
If you are the senior developer and you notice this, take it upon yourself to help educate the junior developer. Ask the manager if you can be responsible for a portion of the tests and help educate the junior developer about the process. In the long run it will make your job easier having multiple people on a team that can perform the task well.
If you are the junior developer, your career is ultimately your responsibility. You should speak to the manager and request that a senior developer work with you for a portion of the tests. If the manager disagrees, take it upon yourself to get the training you need to perform the task. Start with reading as much about testing as you can, then try going to a local user group. Local user groups often have "hack nights," where they get together and write code, allowing you to learn with your peers.
1.3.3. Tests Cannot Be Created for Legacy Code
Testing legacy code is often more difficult, but it's not impossible. Often, legacy code has not been architected in a way that allows unit tests to be created, but in most scenarios functional or acceptance tests can be created for them. During the past few years, many patterns have emerged that make testing legacy code much easier. In the testing world, a code base that contains no tests is oftentimes referred to as legacy code. This means that if you're not writing tests as you write your code, all you are doing is simply creating legacy code from day one.
This myth is generally just another excuse for managers that are uneducated about testing patterns. It's a great idea to write tests for legacy code. Oftentimes the developer who wrote the code is not around to maintain it anymore and creating a test suite for the application will help a new developer learn about the app and give other developers a safety net if they need to make changes in the future.
1.3.4. Tests Are Only for Use with Agile Software Development
Unit testing and Test Driven Development are fundamental processes for XP and many other Agile Software Development methodologies. Just because one process uses a great tool doesn't mean it won't fit into your process.
If your manager doesn't like the word Agile, don't refer to the practice of creating unit tests as an Agile process. Just call it unit testing. As a web developer, you may be familiar with Lorem Ipsum. Lorem Ipsum is used as a placeholder for text and is from the Latin work of Cicero's De Finibus Bonorum et Malorum. Lorem Ipsum is intended to have no meaning because customers often focus on the text rather than the layout of the text. Use this trick on your manager. Some managers are not comfortable with Agile processes because of a lack of knowledge or misunderstandings about how the processors work.
1.3.5. Tests Have to Be Created Before the Code Is Written
Test Driven Development (TDD) is a process that we will explore briefly later in this book in Chapter 3, but for now all you need to know is that it's a process where a unit test for a given functionality is created before the code for the functionality is written.
For a TDD purist, this is not a myth and a test has to be created before the code is created. For someone who is new to testing, TDD can be hard. Before a developer thinks about getting into TDD they should first learn what makes a good unit test. In Chapter 4, we will explore what makes good tests and explore both unit testing and TDD.
It's hard to maintain tests. As you begin creating tests for your code, your test suites often become quite large and unwieldy. If your tests are written poorly then they will be hard to maintain just as with other code. With the correct architecture and considerations in the correct place as described in this book, you should find that your tests and the overall system are easier to maintain.
Having a large suite of tests that fully test your application is an investment. It's your job as a developer to convince your manager of the importance of having a test suite that fully tests your application.
You can't automate user interface code. In the past, creating code to automate user interface code has been difficult. Tools such as the MS Test Web Test and WatiN make automated user interface testing possible.
If a manager states that automated user interface testing is not possible, simply point them to the tools. Be aware, though, that automated user interface tests are often brittle and require more time for maintenance than unit tests. In Chapter 5 you will explore automated user interface testing. With the correct knowledge and time, automated user interface testing can be achieved.
Unit tests remove the need for manual testing. Although unit tests will become a valuable resource for your system, they alone do not replace the need for the system to also be manually tested. Unit tests verify isolated blocks, but we need to ensure that the system works as a whole. Manual testing involves ensuring that the system works as expected when everything is deployed correctly. When manually testing the system, not only will you be ensuring that the UI is rendered correctly, but you will also be verifying that the application and UI are actually useable.
Although you can automate different parts of the application, it is not yet possible to automate so that the application can be understood by the end-user and is easy to use. This is a very important stage and has to be performed manually. Without this stage you could create a perfectly working application, however, the end-user may never be able to use it because they simply don't understand the layout and process.
Unit testing is the latest development fad. In the last two years, testing has become a very hot topic with new blogs appearing every few days featuring "experts" who preach that if you don't write tests you are writing shoddy code. With the quick rise in popularity, it's understandable why one would perceive this development practice as a fad. This simply is not true with many of the concepts being promoted today originating many years earlier.
As with the Testing Is Expensive myth, most managers listen to facts. Gather facts and present a strong case about why testing is important. In most situations, someone who is telling you that your code is shoddy because you don't practice a certain testing development practice is not someone you should trust in blind faith. The true experts understand why testing is important and will not try to force-feed it to you. They understand why code is written without tests and will help guide you in the right direction if you let them.
Developers only need to write unit tests. Unit tests are great to have as they help you design code that is testable and the tests act as a safety net when making architectural changes. However, they should never be considered as a substitution to integration tests, functional tests, and acceptance tests. When a tester/developer understands the purpose of each type of test, thinking that only unit tests are needed will not be an issue.
If someone tells you this, you can assume they do not fully understand the differences between unit tests, functional tests, and acceptance tests. Explain to them the differences, what each type of test is, and where they apply.
Testing is easy. Creating tests is very easy, but creating tests that are meaningful is another story. As with many other disciplines learned throughout your development career, the ability to create good tests will come with time and experience. One of the best ways to learn how to create good tests is to do pair programming with a developer who is experienced with creating tests. There are many schools of thought on pair programming: what it is and how best to perform this method of software development. The method I found that works best for me is to work together with another software developer on the same workstation with two monitors, two keyboards and two mice attached. One developer writes the test and the other implements the code to make the test pass. If one developer doesn't agree with exactly what the other is trying to accomplish, they are able to take control of the work station and explain their reasoning. I find that sitting face-to-face works best to keep conversation flowing.
If you have convinced your manager that creating tests is a good practice, it should not be very hard for you to convince them that you need to learn how to create good tests. Chapter 2 includes a section on what makes good tests. Also, there are many training classes put on by top-notch trainers to assist in this area.