> 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?
It looks like you're mixing up two different issues here: 1) Number of assertions per test 2) Test dependencies The lack of dependencies in the current suite is a source of concern to me. The number of assertions, less so. I'd just do DESCRIBE on a test result and then see the failed assertion. > 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. No, the second assertion is also important, but it likely has nothing to do with circularity issues and should go into a separate test case. > If I'm wrong, please enlighten me; I'm certainly not above criticism. Let's continue this discussion, it might lead to some good decisions. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
