On 1:59 PM, Vicente Botet wrote:
Jim Bell wrote:
On 1:59 PM, Vicente Botet wrote:
[...] One technique could be to make the transformation by hand and keep track of the input -> output association. Another technique consist in re-implementing the algorithm and check that both implementations match.
I more often verify a couple test-cases by hand and encode those, paying special attention to boundary conditions, etc.
Some situations are complex enough that they warrant test hooks to verify intermediate results. And, yes, I leave the hooks in. E.g., "if (test) test->VerifyIntermdiateX(y,z);" Make sure the test-hook pointer is 0 for production.
Hi,
what kind of verification do you use to do?
for example if we had
T complex_transformation(T a) { T tmp1 = simpler_transformation_x(a); T tmp2 = simpler_transformation_y(tmp); return tmp; }
could you complete the example with the use of your test verifications? where do comes test?
You're not using your tmp1 and tmp2 in your example. And if you can come up with simpler_transformation_<n>(), you can test those in isolation. The examples that come to my mind require looking at salient states of a variety of objects, disk files, etc. But the basic form, adapted to your example, would be... static T_test_interface *test = 0; T complex_transformation(T a) { T tmp1 = simpler_transformation_x(a); if (test) test->verify_post_x_pre_y(tmp1); T tmp2 = simpler_transformation_y(tmp1); return tmp2; } A big +1 on inverting an operation, too, when you can.