Close

TestBench 4.2 is out with new convenience methods

TestBench 4.2 brings you a very nice improvement for screenshot testing, a few convenience methods, easier configuration of parallel testing, and bug fixes.

Taking screenshots of individual elements

Using the screenshot testing feature of TestBench makes it easy to validate that your custom application theme is working, or that any large group of components are visually in a desired state. Just call testBench().compareScreen("yourImageName") and TestBench compares the test screenshot with the reference image you set up.

Taking screenshots of the whole application view is in many cases error prone, which means that you need to mask out the volatile parts of your views in the reference images. Masking means that you need to edit the reference image in an image editor and remove parts that you don’t want to have compared. Using the TestBench calculator demo project screenshot tests as an example, in picture 1, I have removed the calculator log part from the comparison by setting it as transparent.

Masking out parts of a screenshot reference
Picture 1. Masking out parts of a screenshot reference

TestBench 4.2 introduces screenshot comparison of individual elements. You can still compare screenshots of a full application, but now you can also query a single component or a layout and make the screenshot comparison only to that component.

Using the same calculator example, I can write

GridLayoutElement keypad = $(GridLayoutElement.class).first();
assertTrue(keypad.compareScreen("myReferenceImageName"));

And the resulting screenshot can be seen in Picture 2.

Taking and comparing a screenshot of a single layout
Picture 2. Taking and comparing a screenshot of a single layout

Convenience methods

Writing more readable code with less characters is always nice, even in test code. TestBench 4.2 brings out a few new convenience methods.

If you found yourself repeatedly writing myWebElement.getAttribute("class").contains("my-style") you can now just write myTestBenchElement.hasClassName("my-style"). The added benefit of this is that hasClassName actually matches only the tested class name, when getAttribute("class").contains("my-style") matches also "my-style-variant” and “my-styles” etc. If you need to match all the style names of an element, you don’t have to write getAttribute("class") and receive a single String, but you can get them in a Set with getClassNames().

Finally, the ElementQuery.last() method allows you to select the last of the matched elements. Query $(HorizontalLayoutElement.class).id("dialog-buttons").$(ButtonElement.class).last() selects the last button in a HorizontalLayout having an id “dialog-buttons”. That’s comfortably shorter than before:

ElementQuery<ButtonElement> query = 
    $(HorizontalLayoutElement.class).id("dialog-buttons").$(ButtonElement.class);
query.get(query.all().size() - 1).

Easier configuration of parallel testing with system properties

When doing parallel testing, you can now configure the test hub hostname with the system property -Dcom.vaadin.testbench.Parameters.hubHostname instead of using @RunOnHub annotation. Similarly, a different system property can be used to configure the test to be run locally on a given browser instead of in a hub. You can write -Dcom.vaadin.testbench.Parameters.runLocally=chrome instead of using the test class annotation @RunLocally(Browser.CHROME).

Having the parameters available makes it possible to configure test runs for different environments. You can, for example, use Maven profiles or set the system properties in CI server settings.

More reasons to update

There are some very useful additions to the TestBench Element classes (see release notes). Maybe the most anticipated one is the ability to get number of rows in Grid by calling GridElement.getRowCount().

TestBench 4.2 also adds a bunch of bug fixes. My favourite fix is adding some missing waitForVaadin calls, which forced me to do explicit waits in some cases of my test code. All-in-all 4.2 is a good minor release. I highly recommend updating.

Vaadin TestBench 4.2

Vaadin 8 beta is out - we need your help!

Update: We are now in RC state, help us to iron out the last bugs before first stable release!

I’m happy to announce that the first beta version of the next major Vaadin Framework release is out. As discussed earlier, version 8 is a huge step forward taking advantage of the greatest and latest Java features. We have worked hard to make some of the core concepts in Vaadin Framework faster, simpler and safer to use, but now we need your help to make sure we haven’t broken essential features and to make the new features even better!

The most exciting new features are:

  • Modern typesafe API optimized for Java 8. The most relevant changes in
    • displaying data in select components and grid
    • binding data to fields
  • Faster (CPU) and more memory efficient data binding
  • Easier to implement custom form fields
  • Java 8 now supported for developing client side extensions as well
  • Improved defaults - less boilerplate code

Refer to the release notes to see the full list of changes. You can also see some code examples from the previous alpha release post and from the preliminary data binding documentation. We are working on publishing a version 8 branch of the documentation side by side with the stable documentation.

Although some of the core concepts have been completely renewed, upgrading to Vaadin 8 is still pretty easy. All old field implementations and selects using Container-Item-Property style API are still there, but moved to a separate compatibility package. We also provide an easy to use script that will change your code to use components from the compatibility package. Then you can start migrating to new more efficient APIs view by view or just use in the new code you write.

To move faster with the development, we needed to drop support for some legacy technologies. From Vaadin version 8 forward, only Java 8 is supported. Also, your application server needs to support Servlet 3 specification. Vaadin 8 also drops support for some older browsers. If you are using Internet Explorer, it has to be version 11.

How to try it out?

The new project wizard in Eclipse plug-in dialog doesn't work yet with the beta release. The easiest way to try out Vaadin 8 with fresh projects is to create a project using Maven archetype:

mvn archetype:generate  \
   -DarchetypeGroupId=com.vaadin  \
   -DarchetypeArtifactId=vaadin-archetype-application  \
   -DarchetypeRepository=https://maven.vaadin.com/vaadin-prereleases  \
   -DarchetypeVersion=8.0.0.rc1

Once you have the project ready, just import the project to your favourite IDE. The pre-releases repository also contains compatible integration libraries for CDI and Spring, both with version 2.0.0.rc1.

Alternatively you can try out the upgrade script for existing applications:

  1. Download the jar file
  2. Execute the script from project root: java -jar path/to/your/framework8-migration-tool-8.0-SNAPSHOT.jar
  3. Add pre-releases repository to your project, see releases page
  4. Change project dependencies:
    1. vaadin-server to vaadin-compatibility-server
    2. vaadin-client-compiled to vaadin-compatibility-client-compiled if you are using DefaultWidgetSet
    3. If you are using CDI or Spring, update related Vaadin libraries to 2.0.0.beta1
  5. Recompile the widgetset if you are using add-ons

Let us know what you think

We have been working hard on the stuff and want to push it out as a stable release soon. Thus I encourage all Vaadin users to try out the new beta release and give us some feedback of every concern you have. There are probably still bugs and API decisions we haven’t thought well enough, so now is the time to get those fixed.

Let us know what you think and let’s make this the best Vaadin release so far. Report all findings through GitHub or forum. Big thanks in advance!

Release notes for Vaadin Framework 8.0.0.rc1

Microservices and Vaadin UIs

If you have been following the web development industry in the last years, there’s a good chance that you have at least heard about microservices architectures. Some would say microservices are a specialization of SOA, others that microservices are the same as SOA, or that microservices are SOA done right. In any case, you might be wondering how to take advantage of the knowledge around microservices. Is it a good architecture for your project? How can Vaadin help in microservices architectures?

In this article, I will talk about the role of Vaadin applications in microservices architectures and provide some guidelines to help you decide on when and how to use microservices with Vaadin.

What are microservices architectures?

Microservices architectures are about modularization. The key term in how modularization is done in microservices architectures is the process. Each service, or microservice, runs as a separate process that can be independently deployed. This makes it possible to use heterogenous technologies, to horizontally scale by starting additional instances, to replace parts of a system (a microservice), and to add resiliency mechanisms than run when a part of the system doesn’t work. This might sound like nothing new, but think of microservices architectures as a revamp of existing practices while reading this article.

Another aspect of microservices architectures is that they help in big projects. Amazon, Ebay, and Netflix are often cited as examples where microservices solved architectural problems. On the other hand, each microservice should be “small”. Defining what’s small and what’s not depends on each project, so ask yourself whether your project “feels” too big for your team. If the answer is yes, consider microservices. If the answer is no, don’t use microservices. In any case, you can benefit from the techniques frequently used in microservices architectures. Just remember not to fall into the “nanoservices” antipattern.

Where do UIs fit in the microservices model? It depends on the specific requirements. It might be that a single UI is the best approach to make your microservices available to people. This could mean that the UI is small enough to be developed by a small team of developers, for example. However, sometimes it makes sense to have separate UIs as separate microservices (deployed independently). For example, the system might serve to many business units with heterogeneous groups of users where each UI can be developed independently.

Single UI

This is probably the best scenario for most projects and Vaadin can easily fit in. Ideally, a UI is all about view logic without any business logic at all. If you can think of the UI as a tool for the data, then providing a single microservice that acts as a human front-end for your project is a good approach in a microservices architecture.

How does a Vaadin application communicate with other microservices? Because your Vaadin code is Java running on the server side, you can consume other microservices using any Java technology to connect to them. There are a few patterns or techniques that you should at least consider when consuming microservices from a single Vaadin UI.

First, use a service registration and discovery mechanism. This allows the clients of a service to locate services in environments where the exact location of a service might dynamically change. Usually, client microservices will consult a centralized registry for the location of a microservice.

Second, use an API gateway when a client needs to invoke calls to several microservices with probably different communication protocols. Not only might this reduce network traffic, but also reduce the complexity of the client code. However, if your microservices are running on the same network, the API gateway might not be necessary when using the same connection protocols among them. In this situation, a Vaadin UI probably has a strong and fast network connection to the microservices and caching can be done at the UI level (and it’s often done somewhat automatically, for example in Grid rows).

Could this become a big monolith? Maybe. Not all monoliths are bad, though. But, if you really think you’ll have to face the typical problems associated with big monoliths in your Vaadin UI, you can consider splitting it into several individual projects.

Multiple UIs

Some authors and developers advocate for creating one UI per microservice. Before going this way, carefully think if this would be beneficial for your project. Software architecture should not be a goal but a tool. To fully harness the benefits of a microservices architecture, each microservice should work independently. The ideal scenario when having multiple Vaadin microservices is that each one can be visualized independently, in different browser tabs, for example. There is no need to add special configurations in the case of Vaadin microservices with this approach.

But let’s say you’d like to have separate Vaadin microservices and aggregate them into a “mash-up”. You have three alternatives in this scenario: IFrames, Portlets and UIs embedded directly to a single host page.

The easiest way to integrate several web applications into a single one is by using HTML’s <iframe> tag. You can use Vaadin (BrowserFrame) or any other web technology to develop the mash-up. IFrames are not that bad, however keep in mind there might be some pitfalls.

A good alternative, if you want to go to the route of several Vaadin microservices integrated into a single UI, is Portlets. By using an enterprise portal framework you gain some extra features such as authentication, authorization, and portlets’ inter-communication. Depending on the vendor, it might be possible to fulfill the microservices definition we used in this article, particularly, regarding the ability of microservices to run in separate processes. If you are interested in using portlets, consult the documentation of portal providers regarding support for microservices architectures.

The last alternative is to create a mashup which embeds multiple external UIs hosted in different servers into a single web page. The host page can be implemented with virtually any technology and can naturally be built with Vaadin Framework, as well. The easiest method is to use the Embedded UI add-on. With it, your code will look something like the following:

VaadinUIComponent ui1 = new VaadinUIComponent("http://test.com");
VaadinUIComponent ui2 = new VaadinUIComponent("http://test2.com");

VerticalLayout layout = new VerticalLayout(ui1, ui2);

This approach has advantages and disadvantages, as well. You can use the Vaadin API to easily create the mash-up, but with this add-on you’ll have to use the same Vaadin theme and the same Vaadin version in all the applications.

When using this add-on, or manually embedding UIs in HTML, you have to enable Cross Origin Resource Sharing (CORS) in your microservices. The Embedded UI add-on contains helpers to achieve this.

Conclusion

Microservices architectures solve problems in big applications by dividing a system in several microservices implemented, deployed, and run independently. Even when the term “microservices” might be considered a buzzword, I’d suggest embracing it and taking advantage of the modernized techniques that the microservices movement is generating. Even when microservices are used in big systems, you don’t have to be Amazon, Ebay, or Netflix to take advantage of this techniques. I’m working on a hands-on, more down-to-earth, practical guide that shows how to implement a microservices architecture. Stay tuned and be ready to get your hands dirty.

Contact our consultants for help with setting up your microservices project