Tapestry 5
  1. Tapestry 5
  2. TAP5-758

Move TapestryTestConstants from tapestry-test into tapestry-core, so that non-selenium test code does not need to use tapestry-test

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 5.1.0.5
    • Fix Version/s: None
    • Labels:
      None

      Description

      The tapestry-test module is meant to be "just a couple of base classes to make it easier to build integration test suites around Selenium.".

      However, org.apache.tapestry5.internal.test.PageTesterContext for tapestry-core uses TapestryTestConstants from tapestry-test. So it seems that anyone doing any kind of tests requires the tapestry-test module and so also imports all the selenium dependencies.

      That dependency problem could be resolved by moving TapestryTestConstants into tapestry-core.

        Activity

        Hide
        Igor Drobiazko added a comment -

        This issue conflicts with TAP5-952

        Show
        Igor Drobiazko added a comment - This issue conflicts with TAP5-952
        Hide
        Paul Field added a comment -

        It's possible that you need several modules to manage the dependencies properly.

        For example:
        tapestry-test contains EasyMock/TestNG code and general test code such as TapestryTestConstants
        tapestry-selenium includes the selenium code (and depends on tapestry-test)

        If you want to be really serious about dependencies and what you force clients to include (which is more important in the OSGi world), you could break the modules down further:
        tapestry-test - generic test-related code for Tapestry
        tapestry-easymock - adds easymock specific extensions for working with Tapestry
        tapestry-testng - enhancements to TestNG to simplify testing Tapestry
        tapestry-selenium - enhancements to Selenium to simplify testing in Tapestry

        I'm not saying that module breakdown is correct, but I'm suggesting that having more modules at finer granularity is something to consider - remember some people prefer Mockito to EasyMock; some people prefer JUnit4 to TestNG; and finer-grain modules give more flexibility and choice.

        Show
        Paul Field added a comment - It's possible that you need several modules to manage the dependencies properly. For example: tapestry-test contains EasyMock/TestNG code and general test code such as TapestryTestConstants tapestry-selenium includes the selenium code (and depends on tapestry-test) If you want to be really serious about dependencies and what you force clients to include (which is more important in the OSGi world), you could break the modules down further: tapestry-test - generic test-related code for Tapestry tapestry-easymock - adds easymock specific extensions for working with Tapestry tapestry-testng - enhancements to TestNG to simplify testing Tapestry tapestry-selenium - enhancements to Selenium to simplify testing in Tapestry I'm not saying that module breakdown is correct, but I'm suggesting that having more modules at finer granularity is something to consider - remember some people prefer Mockito to EasyMock; some people prefer JUnit4 to TestNG; and finer-grain modules give more flexibility and choice.
        Hide
        Howard M. Lewis Ship added a comment -

        We're looking to deprecate the test support in Tapestry, in favor of Spock and Geb.

        Show
        Howard M. Lewis Ship added a comment - We're looking to deprecate the test support in Tapestry, in favor of Spock and Geb.

          People

          • Assignee:
            Igor Drobiazko
            Reporter:
            Paul Field
          • Votes:
            3 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development