Skip to content

Support capturing separate screen recording files specific to each test method when reusing a single instance of BrowserWebDriverContainer for multiple test methods #3998

Open

Description

@erdi

Starting a new instance of a browser for each browser test is costly. That's why Geb has a WebDriver instance caching mechanism which allows to save time by using a single instance of the driver and hence the browser across all of the tests. The browser state (cookies and web storage) is also managed to prevent it bleeding from one test to another.

BrowserWebDriverContainer comes with a very neat support for recording the screen of the driven browser. Unfortunately it seems to be implemented in a way which assumes that both the browser and vnc recording containers will only be used for a single test method and then discarded. In geb/issues#630 we've been discussing with @leonard84 that it would be good to make it easy to use the screen recording support provided by Testcontainers from Geb. To be able to achieve that we would need to make it possible to capture separate screen recordings for multiple tests using a single BrowserWebDriverContainer instance. I could probably come up with some hacks or workaround for this problem but I believe that in the interest of users who might be familiar with BrowserWebDriverContainer and myself who would need to then maintain such hack/workaround it's best if that's actually added to Testcontainers.

I would like to propose adding a mode to BrowserWebDriverContainer which would restart the vnc container every time afterTest() is called on it. I'm willing to work on a PR with the necessary changes but before I do I would like to ask if such a contribution has a chance of being accepted. I can see this being somewhat against the design philosophy of Testcontainers where GenericContainer implements org.junit.rules.TestRule in a way where the container is started prior to the statement (single test case or the whole class depending on the rule annotation used) being executed and stopped afterwards. Therefore I'm asking this question upfront to avoid wasting my time and effort if such a change is unlikely to be accepted.

Activity

  1. bsideup commented on Apr 15, 2021

    @bsideup
    Member

    Hey @erdi,

    Have you considered doing something like this?
    #320 (comment)

  2. leonard84 commented on Apr 15, 2021

    @leonard84
    Contributor

    @bsideup while that works I don't think it is a very elegant solution, maybe it is the best for junit4, but newer frameworks allow better extensions. IMHO it would make sense to give the BrowserWebDriverContainer the necessary functionality to start a fresh recording. Instead of forcing every user to wire it up again.

  3. kiview commented on Jul 2, 2021

    @kiview
    Member

    I think adding this behavior to afterTest() of BrowserWebDriverContainer should indeed work without breaking any existing functionality. The actual implementation could also be similar to #320 (comment) (e.g. just restart the VncContainer part).

  4. MartinAhrer commented on May 13, 2024

    @MartinAhrer

    I have been running into the same issue and acknowledge that #320 kind of can solve the issue. However, this requires that quite some stuff needs to be reimplemented like org.testcontainers.containers.BrowserWebDriverContainer#retainRecordingIfNeeded to get proper handling of recordingMode, vncRecordingDirectory, etc. and retain the same functions as with the current implementation.

    How about having either the vncRecordingContainer as protected property so afterTest can handle all of that or a method like

    reinitializeVncRecorderContainer() {
      vncRecorderContainer.stop();
      vncRecordingContainer =
                    new VncRecordingContainer(this)
                        .withVncPassword(DEFAULT_PASSWORD)
                        .withVncPort(VNC_PORT)
                        .withVideoFormat(recordingFormat);
      vncRecorderContainer.start();
    }
    

    I think this is just a bit of refactoring that won't break any existing solutions.

  5. added a commit that references this issue on May 13, 2024
    ee9c98b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions