Showing server errors in test output during Django StaticLiveServerTestCase?

Question

Is there a way to show the errors that occurred on the server during a StaticLiveServerTestCase directly in the test feedback? That being, when some server function call errors and page just doesn't show up, the test execution by default has no knowledge of the server error. Is there someway to pass that output onto the testing thread?

Preferably the these errors would show up in the same place that errors directly in the test code execution show up. If this isn't (easily) possible though, what's the next best way to quickly see those server errors?

Thanks!

Code (as requested):

class TestFunctionalVisitor(StaticLiveServerTestCase):
    def setUp(self):
        self.browser = webdriver.Firefox()

    def tearDown(self):
        self.browser.quit()

    def test_visitor(self):
        self.browser.get(self.live_server_url)
        self.assertEqual(self.browser.title, "Something")

...

class Home(TemplateView):
    template_name = 'home.html'

    def get_context_data(self):
        context = {}
        MyModel = None
        context['my_models'] = MyModel.objects.all()
        return context

This has been significantly altered to make it simple and short. But when MyModel is None and tries to call objects.all() the server has a server 500 error, but all I get is the "Something" not in self.browser.title error from the test output, when I'd like to see the NoneType has no... error in the test output.

Possible duplicate of [How do I debug error 500's served up by the DJango test server?](http://stackoverflow.com/questions/8159414/how-do-i-debug-error-500s-served-up-by-the-django-test-server) — Ryne Everett, Sep 17 '16 at 05:40

Dmitriy Sintsov · Answer 1 · 2017-11-08T07:48:12.117

To see the errors immediately, run the test in DEBUG mode:

from django.test.utils import override_settings

@override_settings(DEBUG=True)
class DjkSampleTestCase(StaticLiveServerTestCase):
    # fixtures = ['club_app_phase01_2017-01-09_13-30-19-169537.json']

    reset_sequences = True

But one should also configure logging of server-side errors, either via custom django.core.handlers.base.BaseHandler class handle_uncaught_exception() method implementation or via sentry.

score -1 · Answer 2 · edited Sep 11 '17 at 18:52

I use to override the default logger using:

import logging
logging.basicConfig(level=logging.DEBUG, format='%(asctime)s - %(levelname)s -%(filename)s:%(lineno)d - %(message)s')

This will display stderr on your terminal. You can even do:

logging.debug('My var %s', var)

I only do this for debugging, if you want to use logging for non-debugging things I'd suggest to create custom loggers.

More details about logging:

alecxe · Accepted Answer · 2016-01-23T19:50:57.407

-4

This is exactly why it is recommended to have much more unit tests than integration and UI/end-to-end. Aside from other things, the latter don't provide you with a specific feedback and you often need more time debugging and investigating why a UI test failed. On the other hand, when a unit test fails, it is usually a failure or an exception pointing you to a specific line in the code - you get the "What went wrong" answer right away.

In other words, the point is: Cover this particular problem with unit tests leaving your UI test as is.

To help you gather more information about the "Something" not in self.browser.title failure, turn the logging on and log as much details as possible. You may also use the built-in Error Reporting and, for instance, let Django send you an email on 500 error. In other words, collect all the details and troubleshoot the failure manually.

edited Jan 23 '16 at 19:50

answered Jan 23 '16 at 19:45

alecxe

462,703
120
1,088
1,195

I do plan to have more unit tests. But I'm actually trying out TDD and so I'm writing the functional test which leads me to what unit test I should be writing next. So these unit tests will go in place soon. But there's not a particularly good way to get these unit tests to show up in the output easily without manually looking somewhere else? (I'm mostly talking about local testing if that makes any difference) – Jenny Shoars Jan 23 '16 at 22:38
Oops, perhaps my IDE was just being a bit too "smart". It looks like the errors I was looking for were already being shown in the console output, but when clicking on the specific test I only saw the output of the client part of the test. – Jenny Shoars Jan 23 '16 at 23:13
@JennyShoars good to hear you've found the server-side errors logged. You should probably add some details, make an answer and accept it. Hope my answer was at least partially helpful. Thanks. – alecxe Jan 24 '16 at 00:37
It was, but I'm going to leave this open for a couple more days simply because there are other logging options that someone might have a clever idea about. – Jenny Shoars Jan 24 '16 at 07:34

Showing server errors in test output during Django StaticLiveServerTestCase?

3 Answers3