| Q1: | What happens if the three-layer architecture model is not used in an application? |
A1:
| If there is no clear separation between the top two layers, the system under test will have to be tested through the user interface. As we discuss in Chapter 32, the Fit tests do not necessarily have to be written to explicitly use the user interface, however. |
| Q2: | Does the code in the bottom layer ever need to be changed for testing? |
A2:
| As we'll see in Chapter 33, a suite of Fit tests may run too slowly when they are applied to the whole system. Slow tests mean that feedback is delayed, which tends to encourage larger changes to be made before testing that the changes haven't broken the system.
So it pays to have the tests run quickly. There are two bottlenecks: testing through the user interface and database accesses. The first can be reduced by having more of the testing done directly through the domain layer. The second can be reduced by having more of the tests work without the data source layer connected at all. |
| Q3: | But doesn't that mean that you're not testing the whole system and will miss bugs? |
A3:
| Yes. However, there is an important trade off here, and there are ways to handle it, as we discuss in Chapter 33. |
| Q4: | Our major problem is in understanding how our software can meet market need. How do Fit tests help us? |
A4:
| Fit tests can help in exploring and communicating what your system does, or can do. They can give you a way of discussing possibilities before implementing anything.
But the first step can be difficult, regardless of such tools. What significant issues do potential buyers face that are within the realm of your system? How can you solve their problems cost-effectively? How do you get their attention? |
No comments:
Post a Comment