Qadenz 2.0.0 is coming
When I first set out to build the latest iteration of tooling that became Qadenz, I really didn’t expect to hit a 2.0.0 milestone for a good long while, if ever. Here we are now, a couple years after the initial 1.0 release and the first functionality release since that time, and already we’re bumping to 2.0.0. I guess I’ll have my words on a platter with a side of potatoes.
What’s changing?
While adding the new Temporal and Numeric Conditions and Expectations, I made the decision to do some redesigning of how these components were built. I’ll go into more detail in another post on the topic, but the short story is the evaluative logic in the library got repackaged, and now Conditions and Expectations both live on their own. Everything is still there… it’s just presented a little differently. This represents a breaking change in consuming projects, and serves as the technical reason for a major version increment (following the Semantic Versioning model). Consuming projects will need only to update their imports.
As I mentioned, the Temporals and Numerics are the big new feature. These bring the ability for a test to parse the text of an element as either a Temporal (LocalDate, LocalDateTime, LocalTime) or a Number (Integer, Double), respectively, and perform validations using these APIs leveraging some of the capabilities and features of these classes.
Other changes in the release include an ability to retrieve text from an element directly while ignoring text shown in any child elements, removal of the auto-maximize browser logic in the WebDriver setup, and some added convenience for passing collections of Conditions to either the verify() or check() methods.
Full release notes will be published when it’s all done, but the Milestone can be reviewed for a listing of all the Issues and Pull Requests that are in scope.
A major version, though?
I said above that there was a technical reason for the major version increment. The other side of this has to do with maturity of the project and crossing that threshold from making something work, to getting it done right. A number of things in Qadenz were built in a way that was either what made sense at the time, or were the result of my own skill as a developer when each component was built. A conversation with Matt really hit home when the topic turned to Qadenz-1.0.0 being an MVP of the potential in this project. Following that chat, I decided to make what I had originally planned as the 1.1.0 release the 2.0.0. There are still plenty of areas that I’d like to go back and make better. This release, as it happened, focused on Conditions and Expectations.
I’m viewing the 2.0.0 series of releases as the opprtunity to take this project from “just some automation code I’ve been tinkering with for years” to a more serious project that from which, as I would hope, some teams out there could really see some value.
So, will there be a 3.0.0? I’ve learned not to say no to something like that, but I think there’s a good ways to go before that would happen.
So where’s the code already?
The Release PR is open at the time of this writing. I’ve frozen the feature scope, and any small changes made prior to release will be to address any major issues or other items that need to be done before the final merge. There isn’t a preview release in Maven Central for this one like there was for 1.0.0, but the release-2.0.0 branch can be pulled down and built locally for use as a dependency in a consuming test project, should anyone wish to tinker.
My focus at the moment is overhauling the documentation on this site to not only include the new features, but also to be a little more useful. In my first iteration, I think I was able to cover much of the “what” and “where”, but perhaps maybe not enough “how” or “why”.
As for the “when”, the answer is “soon”. I hope to be ready in the next few weeks.
Hello, Hugo
I’m not an expert on static site generators. What sparked my initial interest in the beginning was really just the idea that I could stand up a decent looking site in little time and host for free on Github instead of paying for a bunch of hosting features I neither need nor want. Fortunately, the community around tools like Jekyll and the availability of open source themes made the job of getting a personal profile page up and running quite simple, and the learning process was very satisfying. When the time came to release Qadenz, I knew I needed some place to host some documentation, else I’d be sealing it’s fate that it would never see any use beyond myself and my teams.
Github wikis seemed a logical solution for this at first, but I wanted something different (having worked with GH wikis at a number jobs), something that I could make a better presentation of the content and maybe engage just a bit with any users that found their way to my work. I had already used Jekyll to build a couple iterations of a personal site, so after settling on a name for the library (which had up to that point simply been called “Automation”) and registering some domains and finding a really nice theme called Docsy, I got to work.
Transitioning from Jekyll to Hugo
My interest in Hugo came along after discovering that the Selenium project was also using Docsy to organize their documentation. I had only heard of Hugo at the time, but if the pros on the Selenium project were using it, it was probably worth a deeper look.
Installing Go and setting up Hugo was way faster than getting a Ruby environment stood up and installing Jekyll. Configuring the site and running locally were very easy, and it wasn’t much of a chore to track down the spots where I wanted to make some small UI tweaks. I also opted for a “mostly-docs” configuration as I really didn’t feel the need to have much more than the documentation and a blog on the site.
Getting the site published to Github Pages was the trickiest part, but admittedly a lot of that came down to me learning my way through Github Actions at the same time. One advantage the Jekyll version of the site had was deploying the site to the live environment was baked right into the repo features. I ultimately settled on a first workflow that would set up the build environment, run NPM and Hugo, then publish the site to the gh-pages branch of the repo. I configured the Pages options to auto-depoy on any push to the gh-pages branch, so the baked-in workflow to deploy the site works it’s magic, and out comes a nice looking site full of documentation.
One item of note that I’m particularly happy about is that the Hugo version of the site was much easier to get Google Analytics up and running. I’m not sure why, but I was never able to get it working with the Jekyll version. That’s hardly a knock on the docsy-jekyll project though. I very likely missed a setting along the way that would have made it work. I never saw anyone else complaining that it didn’t work, so it couldn’t have been a problem in Docsy itself. vsoch and her contributors have built an impressive implementation of Docsy for the Jekyll community.
Onward…
So at this point, the site as it sits today is more or less a direct port of the content from the Jekyll site. I’ve done a number of UI tweaks to match the look and feel of the old site, but more work yet remains. As well, there are a number of instances in the site content where placeholders and such are no longer parsed in the markdown. I’m cleaning these up as I see them, but my focus for the moment is mostly the UI details of the site. I’m planning a bigger overhaul of the documentation that will take care of remaining content issues.
I’ll talk more about it in another post, but I’ve been working on Release-2.0.0 of Qadenz. It’s only fitting that a new version of the code comes with a new version of the docs.