Hi, I just had a revelation, watching Uncle Bob about TDD, combined with my knowledge about electronics design which uses Test Points (both at board level as well as silicon level)
Since Zest "owns" the call chain, we could rather easily design a feature that is the equivalent to Test Points in electronics. Places where values are checked against an expectations. Isn't that what "assert" keyword is all about? Yes and no. Assert keyword can only tell if the value is within an expected range. It is rather difficult to communicate to assert what values are expected right now. What is the purpose of this? Well, I think that unit tests are a little bit "weak" since it is difficult to test that sequencing is correct, that interdependent computations are accurate and many other "functional" and "acceptance" test level issues. I think we can solve this rather neatly, by assembling the "real" application with additional Test Points (well the annotations are there all the time), Memory Es and feed actually data through and validate the results. So how is this going to work? Well, I don't know yet. But I imagine that One test consists of S setup steps, N steps of execution, and M results from T test points. Details not clear yet. I imagine that the Test Point is a combo of a SideEffect, an annotation and Reporting service. I imagine that the side effect has some way to know what is expected to happen at each test point. This is GutFeeling(tm) innovation at the moment, but I think there is strong values in here. As usual, feedback is most welcome... Cheers Niclas
