testit-webtester / webtester2-core Goto Github PK

Mockito released their second major version (v2.1.0). We could use some of the new features and should update ASAP.

The (currently under development - #18) JUnit 5 support module will have many features which are lacking in the JUnit 4 module:

• Page Initialization
• Variables in @EntryPoint annotations
• Replacement of @Primary with a name based concept
• Introduction of the @Managed annotation

All of these should also be implemented for the JUnit 4 module since JUnit 5 will need some time to replace it's predecessor.

Important: These changes should be compatible with the current implementation. The @Resource annotation for instance should still be usable. All code which is replaced with newer implementation (@Resource , @Primary etc.) should be marked as deprecated and removed in v2.2.

Kotlin is currently a hot topic and will only get hotter. I think we can assume that some of our potential users will be using Kotlin to write fixture code.

We should check our current API classes for "compatibility" with the way Kotlin is commonly used. The fixture code should always feel native to the used language.

it is completely possible, that we don't do anything which is not Kotlin-esk!

A little bit of background:
Spring has put a lot of effort into making sure that Spring 5.0 and Spring Boot 2.0 APIs are 100% Kotlin friendly.

We need an in dept documentation / article about the underlying concepts and principles of WebTester 2.

It should cover the following topics:

• Why Interfaces instead of Classes?
• Composition through multiple inheritance over class hierarchy (traits)
• Design of Pages
• Design of Page Fragments
• Nesting of Pages and Page Fragments
• Which methods should be declared on which object

This would make TestClassAnalysisExtension unnecessary and allow us to work towards better decoupling of the other Extensions.

https://github.com/awaitility/awaitility

When using

@Managed
static Browser browser;

in combination with JUnit 5's @Nested test concept, the browser will be initialized multiple times.
This happens because we don't consider the nested scope when managing the browser instances.

As with the BrowserFactory implementatins for Firefox, Chrome, Internet Explorer etc., we should provide an out of the box EdgeFactory for Microsoft's Edge browser.

• The BrowserFactory should be called EdgeFactory.
• Our default performance optimizations should be applied.

Current Documentation shows:
https://oss.sonatype.org/service/local/repositories/snapshots/content/info/novatec/testit/webtester-documentation/2.9-SNAPSHOT/webtester-documentation-2.9-20190712.141410-1.html#_default_properties

Unresolved directive in chapters/configuration.asciidoc - include::/root/work/webtester-documentation/target/generated-snippets/config/default-configuration.snippet[]

It would be great to have an example application to demonstrate WebTester's features and show people how to properly use it's concepts.

Possible metrics to collect:

• Time waited: Track how much time is spend on waiting for something to happen.

Currently it is very cumbersome to handle multiple windows (for example pop-ups) with either Selenium or WebTester. There should be an abstraction layer for seamlessly switching between windows and executing code. Within this issue a concept should be created / discussed.

JavaDoc description of getSeletedIndex, getSelectedValue and getSelectedText says return value of a Select with no selected options is an empty Optional.
But it is the first option of the Select.

In a similar fashion as with @Mapping for PageFragement subclasses we could validate if a Page was initialized for a valid context path / url.

Examples

@ContextPath("/html/index")
public interface LandingPage extends Page {
    // implementation
}

• If the currently displayed page had the URL http://localhost/html/index and an instance of LandingPage is created there would be no problem since the context path matches the expectation.
• If the currently displayed page had the URL http://localhost/html/main an exception would be thrown as soon as a LandingPage instance is being created.
• For page definitions without @ContextPath every URL is valid

The values for
wait.timeout
and
wait.intervall

are read by the DefaultConfigurationBuilder, but only used at one place:
WaitConfig.from(Configuration)

this in turn is only use by the WaitConfig internal "from(browser)" which in turn is only used by "from(pagefragment)". The last one is only used with Wait.until(T fragment)...which again is only used by Mouse.moveTo().

Nowhere is the WaitConfig overwritten by the configured properties.

The test sometimes fails for me with:

Failed tests:
  WaitUntilAnnotationFeatureTest.demonstrateWaitUntilVisible:35
Expecting:
 <498L>
to be greater than:
 <500L>

Tests run: 430, Failures: 1, Errors: 0, Skipped: 0

This issue can't be implemented until #19 is done!

It should be possible to automatically initialize and register EventListener fields with the Browser's EventSystem. As with @Initialize and @ConfigurationValue multiple Browser fields should be handled by referencing their name as one of the targets.

• static fields are not supported
• only fields annotated with @Registered are considered by the extension
• if a field is pre-initialized it's value will be used by the extension
• if a field is not pre-initialized a new instance for the field's type will be instantiated using the default constructor
• all of the defined EventListener fields are registered at the beginning of a test and de-registered at it's end
• the extension is executed after Browser fields were initialized
• in case there is only one @Managed Browser instance, this instance should be used to register the listener at
• in case of multiple @Managed Browser instances, the name should be used to identify one or mor targets to register at

@RunWith(WebTesterJUnitRunner.class)
public class SingleBrowserTest {

    @Managed
    Browser browser;

    @Registered
    MyEventListener created; // will have new instance

    @Registered
    EventListener preInitialized = new MyEventListener(); // this instance will be used

    ...

}

@RunWith(WebTesterJUnitRunner.class)
public class MultiBrowserTest {

    @Managed("browser-1")
    Browser browser1;
    @Managed("browser-2")
    Browser browser2;

    @Registered(targets="browser-1")
    MyEventListener forBrowser1;
    @Registered(targets="browser-2")
    MyEventListener forBrowser2;

    @Registered(targets={"browser-1", "browser-2"})
    MyEventListener forBothBrowsers;

    ...

}

As with the webtester-support-junit4 and webtester-support-junit5 modules, it would be nice to have a webtester-support-testng module which offers the same kinds of features as the JUnit modules.

• Browser management
• Entry points
• Configuration value injection
• Page initialization
• Event Listeners

Currently the @Mapping and @Mappings annotations are not inherited in case the annotated class is subclasses.

Example:

@Mapping(tag = "foo")
public interface FooFragment extens PageFragment {
    // can only be initialized for <foo> elements
}

public interface SpecialFooFragment extens FooFragment {
    // can be initialized for every element
}

The behavior should be changed in a way that inherits the annotation if it is not overridden by the subclass.

Unmarshalling of primitive object types should be handled in DefaultUnmarshaller. This may require a redesign of the ConfigurationUnmarshaller interface.

It should be possible to automatically initialize and register EventListener fields with the Browser's EventSystem. As with @Initialize and @ConfigurationValue multiple Browser fields should be handled by referencing their name as one of the targets.

• static fields are not supported
• only fields annotated with @Registered are considered by the extension
• if a field is pre-initialized it's value will be used by the extension
• if a field is not pre-initialized a new instance for the field's type will be instantiated using the default constructor
• all of the defined EventListener fields are registered at the beginning of a test and de-registered at it's end
• the extension is executed after Browser fields were initialized
• in case there is only one @Managed Browser instance, this instance should be used to register the listener at
• in case of multiple @Managed Browser instances, the name should be used to identify one or more targets to register at (if not, an exception should be thrown)

@EnableWebTesterExtensions
public class SingleBrowserTest {

    @Managed
    Browser browser;

    @Registered
    MyEventListener created; // will have new instance

    @Registered
    EventListener preInitialized = new MyEventListener(); // this instance will be used

    ...

}

@EnableWebTesterExtensions
public class MultiBrowserTest {

    @Managed("browser-1")
    Browser browser1;
    @Managed("browser-2")
    Browser browser2;

    @Registered(targets="browser-1")
    MyEventListener forBrowser1;
    @Registered(targets="browser-2")
    MyEventListener forBrowser2;

    @Registered(targets={"browser-1", "browser-2"})
    MyEventListener forBothBrowsers;

    ...

}

Currently the WebDriver's implicit wait can collide with our Wait-API. The implicit wait should be configurable via the Browser. This way we could provide more dynamic options, like a temporary setting, etc.

NEEDS TO BE DEFINED...

Cache should be a ConcurrentHashMap
private static final Map<ClassLoader, Map<Class<? extends Page>, Class<? extends Page>>> CACHE = new ConcurrentHashMap<>();

There should be a special factory for the RemoteWebDriver including named configuration properties.

We need a (short) migration guide for the transition from WebTester v1 to v2.

It should cover the following topics:

• Changes to IdentifyUsing
• Changes to Pages and Page Fragments
• Changes to Wait API
• Changes to the Browser abstraction
• Changes to the Event System

The following modules should be removed:

• webtester-support-firefox
• webtester-support-ie
• webtester-support-marionette
• webtester-support-chrome

To replace them, the corresponding factory implementations should be moved to the core module. Any driver dependencies must be scoped as optional.