This is another reason why Fusedocs are so powerful. The important part of Fusedocs is the <IO> section. This area tells us what variables the fuse will be given and what variables the fuse needs to create.
For example, it's possible to test a display fuse without a database, even if the display fuse is displaying records from the database. All we need to know are what <in> variables the fuse will be given. If the fuse will be given a recordset, we simply need to simulate that incoming recordset so we can see what happens when that data comes in.
This is the case for any incoming variable. We can fake each incoming variable to simulate how the fuse will react to different incoming variables. As a tester we need to make a decision whether it's reacting properly or not.
This where the <out> variables come into play. Using fusedocs it's possible to validate whether the data being produced by the fuse matches up with the necessary <out> data in the fusedoc.
Once the fusedocs have been tested to produce the desired output according to the fusedoc, the architect plugs the fuses back into the fuseactions.
| Title | Author(s) |
|---|---|
| The Ultimate Testing Process | Steve Nelson |
| Query Sims for CF | Hal Helms |
| Query Sims for PHP | Hal Helms, Bert Dawson, David Hyuck |
| Test Harnesses | Jeff Peters |