Sirius: 1 year retrospective

1 year ago I've started working on the Sirius project. 6 month ago there was the first retrospective where I summarized all achievements and future goals. Generally last 6 years were not the most productive. Nevertheless, there were some achievements even there. So, in this topic I'll summarize again where we are with the Sirius now.

Sirius C#: adding UI Automation library

Recently we've created code interacting with Win32 and Web. Now it's time to expand the coverage to the .NET area. For this purpose we have dedicated library called UI Automation. This library is provided with .NET framework and contains basic API interacting with window objects. At the same time this library can be used for interaction with the standard Win32 controls, however it can be used as an auxiliary modules to expand the coverage of existing library I created before for interacting with Win32 elements. In this article I will create sample control classes and make some demo showing how it works. Also, in this example I'll take the tab control and create simple tests interacting with it. At this point that would be just stand-alone library but in the future it will be integrated into entire Sirius project.

Sirius: half year milestone retrospective

6 month ago I've started working on the Sirius project. A lot of things were done since that time, a lot of things were discovered and a lot of things were changed. In general, a lot of work has been done and more work has to be done. So, the aim of this post is just to make some summary of the work being done so far and further directions definition.

Sirius: ruby package installation testing

All Sirius client components are delivered as installable packages. And for Java and C# they are easy to use just by putting references to appropriate binaries. The Ruby packages are easy to install but it's hard to predict in advance whether they reference properly to all necessary resources. That's because any code becomes accessible via adding reference to the path in the file rather than including package name.

The key difference is that local relative paths work OK only for local sources but when you create Ruby package and install it those paths will be applied relatively to completely different folder. So, if you run local unit tests you don't have guarantee that all the code would work in the same fashion as it would work from the gem location. For this purpose, I've added separate class of tests into Sirius Ruby client packages. This class of tests is called installation tests. The main aim of them is to make sure that all modules are properly accessible after the package is installed. And in general it verifies that packages are operational after installation process.

Sirius: running as windows service

Sirius server part is delivered as a set of Java archives and this part is initiated via command line interface. It brings some inconveniences while running the tests. Thus, before start using client API we should make sure that the server is up and running. Of course, we can do that manually but:

1. we should be able to do that automatically
2. when we test client side we shouldn't touch server side at all

So, it's quite convenient to deliver Sirius Server start/stop process to the system. For Windows it can be done by setting server component as the windows service. Since, Sirius Server is just another Java application it requires some additional efforts for making such task however such task appeared multiple times. Here are the related topics on StackOverflow:

• Install java program as a windows service: Alternative to JavaService?
• How to create a windows service from java app

So, I'm looking for something similar for Sirius Server. In this post I'll describe the settings needed for making Sirius Java application running as the windows service.

Sirius: Adding code style checks

We already set up the build process for Sirius as well as we reserved the placeholders for testing. So, further improvement in this area is to extend build with different tests and checkpoints which make more detail verification. This time we'll add more modules which perform static testing for our components and they should fail the build if static checks didn't pass (especially taking into account that it was initially planned).

What would we look for? Basically that's:

• Conformity to coding standards - all code standards are made to provide unified approach of writing code as well as reading and maintaining it.
• Various cases of improper code usage - a lot of actual application errors are results of improper code use or use of potentially dangerous code constructions. So, the earlier we find them the less number of silly mistakes we take during further testing stages

Actually, we've made first approximation for that while we checked the compilation ability. If system isn't compilable it's not working at all. So, we're just making more detailed checks.

Since Sirius modules use different programming languages the tool set will be varying based on that. We'll use the following tool set for that:

Language	Engine
Java	Check Style PMD
C#	StyleCop
Ruby	rubocop

OK. Let's see how it would be added.

Sirius: adding Web client API

We've done some work for Web core functionality. To make the work complete the client API should be added in the same fashion as for Win32 library. At the end of current development there should be an example how to interact with web using Web client.

The following topics will be covered here:

• General Web client architecture
• Web client proxy updates
• Web client class library implementation

Sirius: adding Web core functionality

A lot of work were done for Win32 stuff starting from initial core functionality preparation and up to basic operations implementations as well as handling parent/child windows and user input. So, now we can work with Win32 (not in full extand but at least for base operations). One of the further expansion direction is the coverage of the Web functionality. That's the completely new area for Sirius Test Automation Platform and in this post I'll describe the core part creation which mainly affect server side.

Sirius: Win32 - add Dialog handling and basic input

Recently I've added functionality working with main windows. Next step is to apply functionality to interact with dialog boxes and child controls. It's almost the same except these are child windows and we should carry out additional relationship to main window. Additionally, we should add basic ability to send mouse and keyboard input. Thus, we'll complete basic functionality for Win32. All other code to be written should cover some control specifics rather than common functionality.

Sirius: Adding new component Demo

Here is the demo showing how to add new component to the Sirius platform. The example demonstrates how to create server module from the scratch and how to apply client for this.

Sirius (Java): writing Win32 client library + Live Demo

Recently I described the creation of Win32 server part and at the end I wrote the function which finds the main window by specified attributes and gets the handle for it. This is quite fundamental thing as once we have a handle of the window we can send any messages to it simulating various GUI interaction actions. At the same time the server side library contains only set of functions as Win32 API is all about the set of functions. But it's too raw for writing tests. It's much more convenient to apply some object model to the window objects. So, it requires some effort on the client side. In this article I'll describe the process of Win32 client API creation. I'll create classes interacting with top level windows and create some sample test to demonstrate how that functionality works.

The final output will contain the functionality interacting with top level Win32 windows as well as some demo showing how to work with it.

Sirius: modularize the solution

In the previous post I've added another module to support Win32 operations. Actually, there should be a lot of modules to be added. But I put it directly into the Server module. The more components we cover the more modules I have to include. Thus the server code as well as clients become heavy-weight and entire solution becomes huge. But firstly, it breaks one of the ideas of the Sirius platform. It should have an extensible engine which can plug in the modules on fly. Also, it should be adopted to different operating systems (that's why I chose Java as the main language) but what should the Win32 module do, for instance, on Unix? Nothing. So, in such case I don't need to include it. Or even more, I want to make different complectations for Server side depending on what I actually want to use. For this purpose I have to split our components into functional modules and provide the ability to configure what modules I should include. Also, I would be useful to provide the ability to deliver either entire solution or some parts of it. In this post I'll describe the steps for doing this.

Sirius: core Win32 functionality support

Once we've done with infrastructure it's time to work on development itself. Now I'll start working on the functionality performing interaction with Win32 objects. In this article I'll describe basic preparations for Win32 interactions as well as I'll describe the core functionality to capture the window on screen and perform some manipulations with it. And of course this activity is done in the scope of Sirius development. So, it would be bound to the entire architecture of the platform.

Sirius: Testing setup

Since Sirius is going to be used for testing purposes it's not polite to leave it without testing. Major specifics of this solution is that different parts of entire system are written using different programming languages. At the same time all those parts reflect the same functionality. It means that the tests would be the same for all clients. Well, they would be the same for server part as well (at least most of the core tests). It's not very nice to copy/paste them and then migrate to different languages. So, obviously there's going to be a lot of duplicating work. So, I have to do something to minimize that duplication as well as minimize the maintenance effort in case I want to change some tests. It's valid especially for client side as core part doesn't have any local specific logic. All immediate client methods are actually callers for the same server side methods.

So, there's going to be multiple languages but the same interface for tests. It's not trivial solution but I found that.

Sirius: solution improvements

Overview

The more code is prepared the more items require various corrections and enhancements. Also, some things weren't done initially but they were planned. So, in this article I'll describe various changes applied to the entire project. Here I'll cover the following topics:

1. Adding functionality to stop service endpoints
2. Server side updates for more informative generated code
3. Generate Ruby client from Java server code
4. Migrating solution from Ant to Maven

Sirius: First steps

In the previous article we've created basic skeleton for entire solution. Now it's time to add the content. In this article I'll take sample method, write it's server part and create clients for all programming languages we already prepared infrastructure for. The example would be simple but it's enough to find out how it's better to design entire solution and what is the base flow for adding new functionality. Also it would be clearly seem how it is better to use such solution. So, in this article I'll describe the following:

1. Sample server side method creation (actually that would be the sample of SOAP web-service creation on Java)
2. Java client creation
3. Ruby client creation
4. C# client creation

OK. We're good to go.

Sirius: Dev environment setup

Introduction

All right, I've decided to start development but it's not enough just to write the code. I also should be able to build the packages, test them somehow, provide some documentation and do many other activities. But firstly, I don't want to make a lot of routine work by myself. Let the machine do that for me. Also, I want to be sure that the way the system works for me locally is the same as for any other machine. And eventually, I don't want to keep the source code only locally. It's unsafe as my local machine can be damaged and all information would be lost in this case. So, we need some additional software which makes the development infrastructure and which should be configured in the way convenient to use.

This article is about to describe the infrastructure setup as well as how to configure all this software to point to each other.

Sirius: ice is broken

Pre-phrase

This is the new series of articles dedicated to the Sirius - the new test automation platform development. This is the work I've been doing for several years accumulating different pieces of code with different languages, for different technologies, for different testing types.

The goal of my work is to combine existing solutions under common architecture and represent some unified and extensible design which can be a basis for another brand-new test automation solution or even common platform for delivering test automation types. This is the not the first time I am getting back to this but the more results I get the more different solutions I can integrate under the same framework. I don't expect it to be another widely used platform (I am not even talking about replacement of any vendor tool) but that can be a good prototype. I doubt there were a lot of people who believed in Selenium eight years ago when only some draft version appeared. But take a look at the situation on test automation market now. Selenium became one of the most popular test automation tools and the popularity is growing. Even QTP loses its positions and now it's quite easy to find test automation specialists who are familiar with some popular programming language like Java, C#, Ruby, Python, PHP and many others which were traditionally used for development.