Release of DukeScript Selenium

Last week we blogged about how you can use Selenium to do integration tests for DukeScript applications. We’ve been working on improving the webdriver to support as much useful functionality as possible. Today we’re proud to announce the first official public release (0.5.9).

You can get the project on Maven Central:

<dependency>
    <groupId>com.dukescript.api</groupId>
    <artifactId>selenium</artifactId>
    <version>0.5.9</version>
    <type>jar</type>
</dependency>

With DukeScript Selenium you can perform a variety of different test scenarios:

White-Box Tests

White-box tests are tests that require programming skills, internal knowledge of the system, and access to all parts. It’s often hard to achieve that with integration testing frameworks, as most of them only give you access to the view.

But white-box tests of the UI are important, because you need to make sure, that your bindings work correctly. Otherwise you’ll get in trouble when refactoring the viewmodel. With DukeScript Selenium, you have access to the UI, as well as the viewmodel. So you can unit test the effect of changes to the viewmodel in the view.

Here’s an example:

 @Test
public void whiteBox() {
    // when the application starts the 6 elements should be rotating
    List<WebElement> findElements = driver.findElements(By.cssSelector(".rotate"));
    Assert.assertEquals(6, findElements.size());
    WebElement get = findElements.get(1);
    Assert.assertEquals("World", get.getText());
    // if we set rotating property to false the binding should remove the css class 
    testModel.setRotating(false);
    List<WebElement> findElements2 = driver.findElements(By.cssSelector(".rotate"));
    Assert.assertEquals(0, findElements2.size());
}

This type of tests will make you confident that refactorings in the viewmodel won’t break your view.

Gray-box Tests

Gray-box tests are typically integration tests written by developers. The developers need to test a certain behaviour of the application, for example a user story. They have internal knowledge of how the app works, for example, what attributes a dom element must have after a button was clicked.

That’s the most typical usecase for Selenium, so it’s very well supported by DukeScript Selenium:

 @Test
public void grayBox() {
    // User story: User logs in
    // when the user enters the username and password, the submit button should be enabled
    WebElement submit = driver.findElement(By.tagName("submit"));
    Assert.assertEquals(false, submit.isEnabled());
    WebElement name = driver.findElement(By.tagName("name"));
    name.clear();
    name.sendKeys("DukeScript");
    WebElement password = driver.findElement(By.tagName("password"));
    password.clear();
    password.sendKeys("***************");
    Assert.assertEquals(true, submit.isEnabled());
}

Black-box Testing

And finally there’s black-box testing, where tests are typically created by non-programmers. Their purpose is to make sure the application behaves as specified. Other than gray-box tests, the black-box tests can make sure that developers don’t workaround their own bugs.

To support black-box tests in DukeScript, we can use JBehave. These tests require the developers to define Test Steps. After that, non-programmers can combine thes setps into user stories and test them. We’ve described integration of DukeScript with JBehave in one of our latest blogs.

This is what a test looks like:

Scenario: I click the "Start" button

Given The page is loaded
When I click the button start
Then button stop should be enabled
And 6 words should rotate 

So with this little announcement I’d like to wish all of you Happy Holidays and thank you for supporting DukeScript!