Use with Django's StaticLiveServerTestCase

[Hector Parra]

Hi,

I am tying to use capybara.py with Django's tests.
I have seen on github issues that you propose using TransactionTestCase to solve the problem with DB transactions.

I would like to use StaticLiveServerTestCase, which is the usual one to do integration tests. It inherits from TransactionTestCase and starts a web server which is capable of serving the static assets
I have seen capybara.py initializes its own server. Is there a way to to tell capybara.py to use the server created by StaticLiveServerTestCase?

BTW, I am using Selenium with Chrome.

Thank you.

[Ian Lesperance]

From digging around in the Django source code, it looks like that class just uses some WSGI middleware to serve the static files: StaticFilesHandler. Try wrapping your application with it before passing it to Capybara, then using TransactionTestCase as usual:

from django.contrib.staticfiles.handlers import StaticFilesHandler

capybara.app = StaticFilesHandler(app)

--
You received this message because you are subscribed to the Google Groups "capybara-py" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capybara-py...@googlegroups.com.
To post to this group, send email to capyb...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/capybara-py/ae976a53-3e43-4dc3-b700-0c570816648c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Hector Parra]

Hi, I think it is easier to user StaticLiveServerTestCase since it inherits from TransactionTestCase plus runs the Django server (setting the DB connections correctly, erasing tables after each test, etc.).
Actually it is suggested in its documentation for use with Selenium: https://docs.djangoproject.com/en/2.1/topics/testing/tools/#liveservertestcase

This is the code I used and that works:

class CapybaraTestCase(StaticLiveServerTestCase):

    @classmethod

    def setUpClass(cls):

        super().setUpClass()

        @capybara.register_driver("selenium_chrome")

        def init_selenium_chrome_driver(app):

            from capybara.selenium.driver import Driver

            options = webdriver.ChromeOptions()

            options.add_argument('window-size=1200x600')

            options.add_argument('--headless')

            options.add_argument('--disable-gpu')

            return Driver(app, browser="chrome", options=options)

        capybara.default_driver = "selenium_chrome"

        capybara.default_max_wait_time = 2

        capybara.app_host = cls.live_server_url

        cls.page = capybara.dsl.page

        cls.driver = capybara.current_session().driver.browser

        cls.driver.implicitly_wait(2)  # this slows down capybara

    @classmethod

    def tearDownClass(cls):

        cls.driver.quit()

        super().tearDownClass()

    def tearDown(self):

        capybara.reset_sessions()

I have two questions:

1. I have seen that capybara internally creates a Server with a Middleware capable of tracking the current petitions running. Since here I am using an external server (provided by StaticLiveServerTestCase) will there be any problem?
   
2. When using this line cls.driver.implicitly_wait(2)capybara is slowing down. I wanted to give the tests time for the AJAX responses to appear. But seeing the current behaviour I suspect that capybara is handling the wait itself instead of relying on Selenium. Is that right? Should I just set implicity_wait to 0?

Thanks a lot.
To be honest, I have tried another library (splinter) but capybara is much better when handling waits by itself.

[Ian Lesperance]

On Mon, Mar 18, 2019 at 4:08 PM Hector Parra <hec...@parra.cat> wrote:

Hi, I think it is easier to user StaticLiveServerTestCase since it inherits from TransactionTestCase plus runs the Django server (setting the DB connections correctly, erasing tables after each test, etc.).

TransactionTestCase is what provides the database setup and teardown. All LiveServerTestCase and StaticLiveServerTestCase are adding is the running of a live server, which Capybara already provides.

That said, using LiveServerTestCase or StaticLiveServerTestCase with capybara.app_host is a perfectly legitimate approach. 

 

Actually it is suggested in its documentation for use with Selenium: https://docs.djangoproject.com/en/2.1/topics/testing/tools/#liveservertestcase

They probably suggest it because Capybara didn't exist when they wrote that documentation. 😉

I have two questions:

1. I have seen that capybara internally creates a Server with a Middleware capable of tracking the current petitions running. Since here I am using an external server (provided by StaticLiveServerTestCase) will there be any problem?
   
2. When using this line cls.driver.implicitly_wait(2)capybara is slowing down. I wanted to give the tests time for the AJAX responses to appear. But seeing the current behaviour I suspect that capybara is handling the wait itself instead of relying on Selenium. Is that right? Should I just set implicity_wait to 0?

1. There should be no problem as you're using it. If you provide app_host instead of app, Capybara won't spin up a server (it can't, because you haven't given it an app to use).

2. You should definitely not set implicitly_wait. As you've seen, it will slow down a great many things about Capybara.

(To be more specific, it slows down any "negative assertions" performed by Capybara. implicitly_wait causes Selenium to wait up to N seconds for a particular query to return true. If you're trying to assert that something is not on the page, however, this will cause Selenium to needlessly wait for 2 seconds.)

 

Thanks a lot.
To be honest, I have tried another library (splinter) but capybara is much better when handling waits by itself.

Always glad to hear that people are finding it helpful! 

[Hector Parra]

Thanks a lot. Your insights have been very helpful.