On 7/13/06, Malcolm Tredinnick <
[EMAIL PROTECTED]> wrote:
I know Malcolm said he was going to step away from this discussion, so this is mostly for the benefit of everyone else.
While I appreciate what you're trying to say here - test one thing at a time, etc - I can't help but feel that this is overkill. We implicitly trust the Django models and query tools, so end user model tests don't require tests of basic query functionality, but then we put in a complex framework to mock the Django models so that we don't have to use the actual models during testing.
A fixture/db seeding capability provides the same testing capability with very low development effort on our part. While this testing regime is _theoreticallly_ weaker because it relies upon the validity of the models, in practice I don't see that being a very large source of potential error - certainly no larger than the confidence in the mocking framework itself, which will only ever exercised during the test process.
Agreed, but the question that I have is 'what assertions?'
1) We could test that template + sample context -> template output == known template output
2) We could do 1, but assert that template output contains known substring(s)
3) We could parse 1 into a DOM tree and validate the contents of various template tags.
The problem is:
(1) is extremely fragile;
(2) is less fragile, but not especially helpful IMHO,
(3) can only be applied to DOM-like documents.
(2) can be made more helpful with lots of string comparison methods ('n instances of string', 'string 1 occurs before string 2'). However, I'm not sure that it actually serves to validate anything useful. The Django policy of preventing complex logic from being placed in the template means that if you are able to validate at the view level that the correct context has been created and the correct template has been used, the only real test that applies to the template is 'does this page render correctly'. Testing substrings of the generated output doesn't achieve this validation - correct rendering can only be answered by 1) direct comparison with a known correct example, or 2) visual inspection.
Of course, there is the need to test custom template tags and filters, for which (1) is an appropriate solution. However, this requires no additional framework to test - as evidenced by the fact that template tags are already tested as part of the 'othertests' package.
Russ Magee %-)
I know Malcolm said he was going to step away from this discussion, so this is mostly for the benefit of everyone else.
Initially, I think it will be hard to have the views entirely divorced
from the model framework. To do that (separate them for testing
purposes) would require making it very easy to creat mock objects.
While I appreciate what you're trying to say here - test one thing at a time, etc - I can't help but feel that this is overkill. We implicitly trust the Django models and query tools, so end user model tests don't require tests of basic query functionality, but then we put in a complex framework to mock the Django models so that we don't have to use the actual models during testing.
A fixture/db seeding capability provides the same testing capability with very low development effort on our part. While this testing regime is _theoreticallly_ weaker because it relies upon the validity of the models, in practice I don't see that being a very large source of potential error - certainly no larger than the confidence in the mocking framework itself, which will only ever exercised during the test process.
For template testing, I was thinking about passing in an object that
supported the necessary attribute accesses (the beauty of everything
being accessed as "foo.bar.baz" is that faking it is reasonably
straightforward). The test takes the template source filename (or source
string), the canned input data and we can run assertions against the
result.
Agreed, but the question that I have is 'what assertions?'
1) We could test that template + sample context -> template output == known template output
3) We could parse 1 into a DOM tree and validate the contents of various template tags.
The problem is:
(1) is extremely fragile;
(2) is less fragile, but not especially helpful IMHO,
(3) can only be applied to DOM-like documents.
(2) can be made more helpful with lots of string comparison methods ('n instances of string', 'string 1 occurs before string 2'). However, I'm not sure that it actually serves to validate anything useful. The Django policy of preventing complex logic from being placed in the template means that if you are able to validate at the view level that the correct context has been created and the correct template has been used, the only real test that applies to the template is 'does this page render correctly'. Testing substrings of the generated output doesn't achieve this validation - correct rendering can only be answered by 1) direct comparison with a known correct example, or 2) visual inspection.
Of course, there is the need to test custom template tags and filters, for which (1) is an appropriate solution. However, this requires no additional framework to test - as evidenced by the fact that template tags are already tested as part of the 'othertests' package.
Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
