On Feb 6, 1:06 pm, "Leslie P. Polzer" <[email protected]> wrote:
> Include the full widget content in the expected output.
Yes, that occurred to me as well. I think my confusion is due to the
existence of two assertions in the test:
(ensure-null d)
and
(ensure-same (get-output-stream-string *weblocks-output-stream*)
#.(format nil "~
{~
\"widgets\":~
{~
\"a\":\"<div class='widget dirtier' id='a'>42</div>\",~
\"b\":\"<div class='widget dirtier' id='b'>42</div>\"~
},~
\"before-load\":null,~
\"on-load\":null~
}")))))
Two points:
I'm not an expert, but if I remember correctly, isn't it one of the
more important principles of unit testing to have only one assertion
per test? In a practical sense, if something was wrong with a render-
body specialization, many tests will fail; it seems that this sort of
thing is very common in the testing suite and if, say, 350 of the 700+
tests were to fail, how would you go about picking out the real
failures? I suppose some of the complexity would evaporate as
problems were fixed (like fixing syntax errors in C++ templates), but
I'd prefer to see only one test fail for any particular problem.
It seems to me in this case that the *real* test is in
(setf d (list a b))
(weblocks::render-dirty-widgets)
(ensure-null d)
and the rest is just unnecessary (and confusing) maintenance.
If I'm wrong, please enlighten me; I'm certainly not above criticism.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"weblocks" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/weblocks?hl=en
-~----------~----~----~----~------~----~------~--~---
