> Herald, please... > Nobody want discard those tests today and the matter is not today but > tomorrow or aftertomorrow. > Are you 100% sure that you and Patrick will be available to give an hand > to > the guy will see a broken test in NH2583 in the year 2013 or 2014 ?
No - I definitely cannot swear I'll be around! (you know that concept of a "truck number" ... I might be the next guy :-) ). That's why I tried to explain how to go about the failure such tests as an answer to Stephen! I hope that this helps to get aquainted with this sort of tests. And there is even a text about the design of that framework ... which I will rewrite and extend with an explanation like below (which I'd appreciate if Stephen & Patrick could grade a little) after Patrick (and I - and you ... and whoever else) is satisfied with the solution. I think this is (a) necessary [as you point out] and (b) easy enough! Hope you are happy with this! Regards Harald M. > On Tue, Apr 26, 2011 at 10:10 AM, Harald Mueller > <[email protected]>wrote: > > > Hi - > > > > > As an example, if/when any of these tests fail, it doesn't seem as if > it > > > would be trivial (or even straightforward) to determine the *meaning* > of > > > that failure without an inordinate amount of time spent in the > debugger > > (or > > > much worse IMO, spent staring at the test data) to understand just > what > > > exactly failed. > > > > No, that's no so. I know this because some of the tests filed "quite > > nicely" during development (I don't know about Patrick's experience, > > however). The full input coverage creates quite a nice output. I number > all > > the objects per class with a static variable; so if you run a single > test > > (that failed in a regression run), you get a failure like > > > > Expected: <1, 3, 4, 5, 7> > > But was: <1, 4, 5> > > > > So, you knwo that the condition did not work as expected on object 3. > But > > if you now look at the "Setters" definition, you see e.g. that it is > > > > Setters<TK, TBO1_I>(SetK1, SetBO1_I1) > > > > you know that there are 3 * 4 = 1 records in the primary table ("MyBO"), > > which will have the values > > > > K1 BO1.I1 > > ---------------- > > 0 (null) null > > 0 (null) null > > 0 (null) 0 > > 0 (null) 1 > > 0 (zero) null > > 0 (zero) null > > 0 (zero) 0 > > 0 (zero) 1 > > etc. > > > > So you know that the first difference in the 3rd line, which in this > case > > is where K1 is 0 and BO1.I1 is also 0. > > After a few failing tests, you can almost read the "failure data" off > the > > test output. > > > > HOWEVER: My introduction of ValueNull for all possible values creates > > multiple absolutely identical object graphs. The reason is that - as you > can > > see above - for a non-nullable int property (like K1), both TK.ValueNull > and > > TK.Zero produce the same value. Reason: I cannot assign null to K1, so I > > assign 0. A better implementation would throw an exception when trying > to > > assign null to K1; and by this, tell the data generator that this value > does > > not make sense --> then, these objects would not be generated at all. > I'll > > try to change this shortly - and check how much smaller the number of > > objects then gets. > > etc. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
