> That's what I was suggesting; that way the view becomes simple enough that > anyone looking at it can be assured of its correctness, without a host of > unit tests. Those tests can be applied to the functions that actually > construct the messages.
Right, it's really those supporting functions that I need to test, but they currently don't return anything more informative than the view does (i.e. blank HttpResponse) > If this is all for a refactoring, then you're probably on the right track > there -- instrument the existing object for testing, rather than > restructuring the view first. Get the code into a state where you can trust > it, and then you can start restructuring it to make it more easily testable > in the future. Well, it's not just for refactoring -- we're planning to add additional features that will make the state logic even more complex. But if more testable code would require refactoring, I'd like to already have some form of tests in place anyway because there's a decent chance that refactoring without them would break something. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
