Questions & Answers | Q1: | What if the last row of a DoFixture table returns a fixture? Is it used in the next table? | | A1: | A fixture resulting from the last row of a table is ignored. The next table in flow is interpreted by the flow fixture object anew. | | Q2: | Is there any way to have actions follow the rows of a RowFixture in a table? | | A2: | No. RowFixture, the other list fixtures, SetUpFixture, and CalculateFixture all consume the rest of the rows of the table. | | Q3: | Wouldn't it be confusing if a method in the system under test were changed to return an object instead of void? | | A3: | Yes, if that was called directly. The actions following in the table would then be incorrectly applied to that object. It's unlikely that there would be suitable methods, leading to an error. | | Q4: | Isn't this flow stuff too complex, compared to the core fixtures? | | A4: | It seems more complex because it's introduced as a variation of the way the core fixtures work. But once you're familiar with the FitLibrary fixtures, you'll find it's simpler for both the Fit test writer and the programmer. |
Note One of the design goals of the FitLibrary fixtures was to enable inexperienced programmers to use Fit. Writing fixture code is confusing when students haven't yet learned about inheritance and writing subclasses. The FitLibrary fixtures were designed to be used without the need to write any fixture code. This led to the automatic wrapping of returned values with fixtures, such as a List with an ArrayFixture and an Object with a DoFixture, which proved to be more generally convenient to use. |