In a series of posts, I’ve talked about my Tapestry micro-framework and I tried to provide some of the rationale for its design choices. Providing that rationale meant providing a context for you to see it in action. This post will cap off the previous posts by digging into the code of Tapestry a bit and showing you how it works. I hope this is more relevant given that you’ve now seen it in action.
In my last post on micro-frameworks, I got into the organizing principles of my Tapestry solution, by which the framework provides or supports a mechanism for the encapslation of and delegation to logic. Here I’m going to continue on that theme but with a focus on showing how the framework calls into the tests, rather than the reverse, and why I think this is a good design approach.
This is a continuation of my exploration into providing insight into micro-framework creation for automation, using my own Tapestry tool by way of example. The first post set the context and the second post focused on exposing an API. Here we’ll dig into exposing the organizing principle.
Here I want to talk a little about test automation framework construction. Or, rather, micro-framework construction. I will use my own tool, called Tapestry, for this purpose. Tapestry is written in Ruby but what I talk about is potentially transferrable to your language of choice.
As many automation engineers know, we’ve been dealing with Marionette, the successor to the Firefox Selenium driver, for some time now. We’re starting to see a light at the end of the tunnel. However, I’m finding a lot of teams are still struggling with what all of this means. Here I’ll talk real briefly.
In this tutorial post, I’ll begin covering how to apply the screenplay pattern with the Serenity framework. This is a “roll-up your sleeves and code” post. Here I will take a measured approach to demonstrating the screenplay pattern in the context of a working example.
A lot of testers avoid any consideration of C# because it’s a Microsoft created language and the assumption is that it only has relevance on Windows. That’s not true. Just as Java learned a lot (and corrected a lot) from C and C++, C# did something similar with Java. Here I want to focus on how you can use C# on other platforms by creating a test solution in Xamarin.
In this post, I’ll focus on an ecosystem I haven’t given much attention: that of Windows and the use .NET related technologies. I’ll be covering the use of Selenium WebDriver within a C# context.
In this post I’ll focus on using page objects in a Selenium and Cucumber JVM context. Please note that this post follows on from the previous post, using the code you built up there.
I previously posted a tutorial on using Cucumber JVM to test Java code. However, many testers are in the position of using Cucumber JVM to test web-based applications using tools like Selenium. In this post I’ll show how to use these tool solutions together.