Section 1.1.  The Need for Fit

1.1. The Need for Fit Two major, interconnected tasks essential to the value and quality of a software application are Helping to think about and communicate through concrete examples what is needed in a software application Automatically testing, from a business perspective, that the application is doing what is expected and that it continues to do so as it grows in functionality Often, however, these two tasks are carried out poorly, leading to breakdowns in each step along the way from an identified business need to a running application. The business needs are not well understood by those who want the system, owing to a lack of a clear way of thinking about these needs and, more generally, of communicating them. The business needs are not well understood by the developers, and so the application doesn't solve the right problem. The application is of low quality. It is difficult for users to understand and contains frequent faults that users have to work around. Updates are treated with suspicion because they're likely to cause more trouble than they're worth. The more it evolves, the more the application becomes difficult to change. It becomes fragile and easy to break. The developers start to fear making changes. They add redundant code rather than revising the existing code. Fit (Framework for Integrated Tests) is a powerful framework for automated testing to help solve such problems. Fit is especially well suited to testing from a business perspective, using tables for representing tests and for reporting the results of automatically checking those tests. This tabular form enables people with no programming background to write tests and thereby help guide overall development of a needed system. Fit is a general-purpose, open-ended framework that's easy to extend for expressing various sorts of tests. This book shows how to begin to solve several pervasive problems in developing software: Communicating with clarity between the various stakeholders and the developers. What does the system do, and what should it do? Focusing with precision on what needs to be done next. Knowing when something has been completed. Supporting the inevitable restructuring of the code as the system evolves. Ensuring that we know quickly when completed work is broken by mistake. Our focus is on understanding business rules and expressing them with concrete examples in test tables. We distinguish two sorts of business rules: Business rules that calculate something or make decisions, such as a business rule that determines the discount on a purchase Business process, or workflow, rules, which specify how some action is carried out and what the outcomes should be, such as a workflow rule for what happens when a user creates and enters a chat room when connected to a chat server We show how Fit can be incorporated into software development practices, filling a serious gap. This can be done through small steps, avoiding the risks of "big-bang" change. We show that choosing and structuring test examples are crucial. Test examples not only enhance communication between the stakeholders and the developers but also are central to automatic testing. Expressing the tests well in Fit tables begins the design process and allows for managing the inevitable changes in what is needed from the software.