Category: Java

Treading Water Is Too Much Work

I honestly meant to post about the daily insanity of my workplace about a dozen times over the last two months. The only problem was that I was working all the time. Something amazing happens every time I step off the Endless Manual Testing Train To Perdition. I always have a giant pile of technical debt to address and I have to work overtime for weeks to catch up on the deferred maintenance. The current task on the pile is implementing an interface for a REST API to query the customer configuration management application for configurations meeting necessary criteria for automated tests. I didn’t want to use the UI to search for these configurations because the test systems are still a steaming pile of crap. Using the UI introduces a ton of new opportunities for their horrible performance to blow a test execution run to smithereens. Plus, these tests already take long enough to run that any means I have at my disposal to optimize the execution time should be put to work.

The API belongs to an ecosystem of APIs the company developed for programmatically interacting with our services and systems. There is a tool available in the The Chosen Framework v2.0 for executing requests against these APIs, but the design is not to my liking. Given the political shit storm that always surrounds any attempt to alter the design or function of any of the services in The Chosen Framework v2.0 and the total lack of staffing to support and maintain the framework, I decided to secretly write my own tool. There is an overly complex authentication system for using any of these APIs, so I had to build out my model for the access control group and user admin business domain to include the credentials needed for authentication. I have a penchant for wanting all my test data to live outside my test suite source code, so everything needed to be serializable/deserializable from both XML and JSON because who am I to dictate which storage format a person should use in order to employ my tools for their own purposes?

One thing lead to another, and suddenly, I had 6 different repositories for tools I have written to model parts of the business domain and as well as services I built on top of those models to automate interactions with the products I test. Not to mention that the number is set to grow because I have plans for additional services for even more automation goodness. In short, this collection of tools and services has become a total beast. It is really an automation framework in its own right. I finally managed to get a Stash project dedicated to them, so I moved everything there. As soon as I did this, I started to get nervous about getting caught for not using the services in The Chosen Framework v2.0. QA Director has been on the warpath against people who don’t want to use the services in the The Chosen Framework v2.0. I believe that the failed effort to shove it down the throats of other business units in the company is a sour and somewhat embarrassing memory for him, especially because several people on our team have turned their own noses up at various tools in framework. I can only imagine what the reaction will be if I get caught for building a rogue framework.

I confessed to my boss today that I was guilty of coding without a license. He asked me why I didn’t use the existing tool and I explained my reasons, and he said I should just add my tool to The Chosen Framework v2.0. This meant I had to explain that this would mean adding other tools to it, including the business objects and page objects that I had been asked to remove last year. He seemed confused and said he would address the issue in Some Very Important Discussions taking place next week among QA Director, the other managers and Principal SDET regarding the future of The Chosen Framework v2.0. I don’t think he realizes yet what a clusterfuck this whole thing has been. I would prefer to have nothing to do with The Chosen Framework v2.0 and continue building out my secret framework, but I know this is never going to happen.

The summer was a busy affair. It started out with a massive fail by the new organization that has taken over support for development tools and infrastructure. They officially took over maintenance of Stash in June and immediately buggered system the first time they did routine maintenance on it. For some reason, the most recent backup available was a month old. Thankfully, I had the most recent version of all my work saved locally, but some teams lost work. I am very happy to see that we are getting something that looks a lot like a real IT support staff, but these handoffs are a bitch. At the very least, before doing anything to the source control system, one should make a backup and then make a couple copies of that backup and store each of them in different locations. They handled the recovery process well, though, with good communication and organization of the effort to glue Humpty Dumpty together again.

As part of my job duties over the summer, I helped Junior SDET Who Should Be Senior mentor our summer intern from MIT. This was one of the most pleasant and enjoyable experiences I’ve had. It’s a lovely experience to work with one of the smart ones who learns quickly and is able to extrapolate abstract principles from a few basic examples and work independently. I highly recommend hiring MIT students as interns. I think a lot of them could easily drop out of school and start working as developers or even start their own companies and be wildly successful.

QA Director has been on everyone’s case about work from home policies and has lately taken up the cause of monitoring what we are doing on our computers at any given time. At one point, he asked Junior SDET Who Should Be Senior to talk to our intern about not playing games or watching any videos while he is in the office. QA Director claimed that ‘someone’ had complained to him about it, but I wouldn’t put it past him to lie about that so that he doesn’t come off as the ‘bad guy’ with a bad case of Hall Monitor Syndrome. I personally think that people who are productive and hit their milestones should be left alone, but I’m not the boss. Right after this, he claimed that ‘someone’ complained about the whole QA team being absent from the office on the first Friday after a giant release date. This was first and foremost, incorrect because I was in the office that day. I’m just too short for anyone to see my head over the top of my cube. Second, several people took vacation after that horrific release cycle, one of us couldn’t work that day because their new H1B visa wouldn’t be in effect until the following Monday, another of us was out sick and the rest were working from home on Friday because that was the day they had chosen for their one day a week allowance.

This of course, ignited a tense and difficult team meeting in which many of us expressed anger and resentment because developers seem to do whatever they want when they want and we are the only team that ever gets called to account for our whereabouts. QA Director became very defensive and sort of pissed at us and then he said he was going to tell the person who complained to mind their own business. Which is what he should have done in the first place. There’s nothing more demoralizing than a boss or director who won’t stand up for their team. Our team manager seems to be getting really tired of all this and has said he is not going to get into the habit of taking attendance because we are all grown adults and he would prefer to focus on the work and whether it is getting done or not. Although I am really pissed that my former boss was fired, I like the new manager a lot. He’s focused on the work and getting the developers to work together with us as a team, which is nice.

I found a senior developer role elsewhere in the company that is with one of the business units that is turning a profit. I have an informational interview with the hiring manager next week. Hopefully, this will be the right fit because it would be really great if I could continue working with the company in a part of it that is actually making some money. I really like the technology here and working with a core piece of it would be a great opportunity for me to gain some new experience and skills. I am still working on acquiring the knowledge and skills to get into data science or machine learning. I underestimated the amount of time that would take. There’s a lot of math. SO MUCH MATH. I built an Anki flashcard deck for the MIT discrete class I studied through MIT OCW. After finishing up the book and the lectures, I started using it study the material. For the first two weeks, it felt like it wasn’t doing anything for me, but now I have started to see cards which are easy for me to answer. The other benefit is that there are many proofs that I ‘know’, but understand more fully as a result of repeatedly reviewing them. Our summer intern is taking the class this fall, so I shared the deck publicly, and it appears to have taken off like wildfire because it has been downloaded 41 times so far. Hopefully, Anki will catch on at MIT and students will make decks for their other classes and post them publicly so I can use them myself.

I also took on the task of identifying the root cause of some TestNG defects related to parallel test execution. These defects have been making it impossible to implement the ability to log my tests to a separate log file by thread without advanced jujitsu configuration and hacking in Logback. If the tests would just freaking execute in the right thread in the expected fashion, this would be trivial, but all these random extra threads get spawned because a new thread worker is inappropriately spawned when you have test method dependencies. TestNG works as expected when test methods don’t depend on each other. Actually, group and test method dependencies are notoriously buggy when trying to use the various parallel execution modes offered by TestNG. It was quite a ride debugging that code base, but I found the bug in the source code and now I am trying to figure out how to fix it. It seems to be difficult to get a pull request accepted in TestNG (for good reason), but I want this bug fixed so bad, I am willing to jump through whatever hoops they want.

Basically, I have a lot of irons in the fire all at once. Hopefully, switching to a role in a profitable part of the company will put me in a less over-burdened role. I am sick of working on an absurdly understaffed team with people in positions of technical leadership who shouldn’t be there because they can’t code or understand basic software architecture design principles. Also, I really want to work for an organization that doesn’t treat me or my team like a bunch of middle schoolers who need a hall pass and a reason to be absent for a bathroom break.

Share This:

Optional Types and JSON Deserialization for C# for Brixen

Every small victory shall be rewarded with the next battle. Now that I have completed the task of doing the C# implementations of all the state beans in Brixen, I am planning the translations of the configuration beans. Preliminary research indicates that the closest equivalent to Java’s Optional type is the Nullable struct. And there is a tool for marshalling JSON data into object instances: Json.NET. Once I had established those facts, I had to tackle the same issue I had when approaching this problem in Java, which is: How do I distinguish between a missing key an an explicitly null value? And I determined that there is no built in way to do this and will require work on my part to make it happen. It also led to a funny Stack Overflow post where someone posted their implementation with the caveat:

I uploaded the implementation into a repository on Github, for everyone to use (no warranty, use at your own risk, etc… I’m in hospital with 6 broken ribs and under painkillers: if something doesn’t work it’s YOUR fault):

So, I will most likely be following the guidance of someone who was under the influence of strong painkillers. I expect this will be an epic journey involving a lot more coding than was necessary to pull off the configuration beans in Java.

Share This:

In Which I Bitch and Moan a Bit More

First, I would like to bitch about C#. I finally translated the whole state Brixen Java bean package into C# and both the C# and Java versions are fully unit-tested. Yay! Second, C# needs something like Lombok _ASAP_. I did not fully understand The Giant Teh Suck So Much that it is to write all this freaking boilerplate for ToString(), Equals() and GetHashCode() over and over again until I enjoyed not doing it for Java classes for the last year. It’s glorious to open up a class file and Not. See. That. Shit. I am bummed there is no way to do the decorator pattern in C# as I have done it in Java. That little beauty of a design pattern _really_ cuts down on boilerplate. And Equals() for collections such as Dictionary, the equivalent of Map for Java, totally blows because it does reference equality, not ‘contains the same shit’ equality like Java Map implementations do. Seriously… what the fuck? Who thought that was a good idea? This took far far longer than I thought it would. I thought I would be done with the C# translation before Christmas and that I would be blazing through the Python implementation by now. Writing unit tests is tedious and time-consuming, but having caught some bugs with them, I am happy I have committed to doing them in tandem with the C# translation. But enough about that. Brixen marches onward and the source is available here. Looks like someone forked my repo a while back. I am flattered.

Today, I am _not_ gruntled. Far from it. You probably would have guessed that from the mere fact that there is a new post today. I had my annual performance review and the result was good, but not spectacular. I feel satisfied with this outcome and it is what I expected. This was a rocky year for me, and I did a few things which embarrassed the QA director. I publicly contradicted his goals and strategy on a fairly high-level initiative he was pushing, and I chewed out the Principal SDET over email for checking crappy page objects into the core of the automation framework without so much as a word with me over it. So, the chickens are coming home to roost for me. I have always had a mouth that got me into trouble before my rational brain could stop me. I have a habit of just expressing things in a way that others find too blunt and not diplomatic enough. I also have a temper.

Today was one of the days in which my rational brain was too slow out of the gate to catch up with my mouth. A junior developer is taking on the task of translating the regression suite I wrote to run against the new, totally rebuilt front end. I expected this task to be difficult for her. The regressions suite tests the application that has the biggest, most complicated UI in the entire customer portal. That shit is hard and complicated and the page object modeling is a non-trivial challenge. Today, she called a code review that included me, the Principal SDET and two other team members. In the midst of the code review, the question came up about labels I have attached to the test cases in JIRA which are reproduced on the test method as group names. I have a longer term plan for using those labels and the group name mappings as a way to dynamically select methods for specific functionality on the fly so that a developer can trigger a build that selects tests that cover the functionality they touched in their commit. Principal SDET claimed I had agreed to take the labels off the Jira test cases and the test methods. Problem is, I have near perfect memory for conversations going back months, and I knew that I had not agreed to do that. In fact, she and the QA director had backed down from it when it last came up. I disagreed with this assertion and before I knew it we were shouting at each other over the phone and she was refusing to explain why the presence of these labels was harmful to anyone.

After a chat with the QA director, I will be doing a presentation next week to explain why I did this and where it is going and then put it forth to the team to decide to chuck this or not. If they decide to chuck it, then I will copy all my work elsewhere and continue implementing a parallel test suite that uses this plumbing and present it to the development team when it is ready because this whole thing was meant to help them anyway. I have no idea where this came from and it is not the first time an issue which had been settled has been raised again from the dead where I am told I have to change how I did something without getting a clear explanation for why I need to. I am getting… weary of this. Principal SDET has a habit of honing in on trivial, non-architectural things which harm no one and making a giant fucking deal out of them. Test data storage formats are a giant bugaboo and apparently everything must and should be stored in a Java Properties file even though Java Properties files are flat, key/value pairs and there is no tooling I know of or that she can point me to which will allow me to suck in a Java Properties file containing serialized data that represents collections of objects and their state and instantiate collections of POJOs with it. At one point, the directory structure of the framework was a giant burning issue. If someone checked something into the wrong directory or tried to use Maven modules to manage multiple, related projects, they were not following ‘architectural’ guidelines. I have no idea what important architectural implications any of this has since they have NO EFFECT on how any particular subsystem interfaces with any other subsystem.

The code review barely touched on anything related to actual form and function of code. I don’t know if it is worth it in the long haul to stick around in this role. I like the challenge of the stuff I work on, but this perennial micromanagement and drama is getting really old.

Share This:

Why Can’t Vacation Last Forever?

I am feeling the post-vacation blues. Not only did I not win the Powerball lottery for the biggest jackpot in American history, I had the unfortunate luck of returning to work in the same week a major release was scheduled to go out. The release was originally scheduled the week before, but it was postponed, leaving me with the unenviable responsibility of being on the conference call for the go-live moment, scheduled conveniently at 11:30 at night. I had volunteered to do the release call while on the vacation, but was told that no one should work on vacation. Frankly, I’d rather do this on vacation because I don’t have to work the next day. I am a cranky jerk when I am sleep-deprived.

The vacation was exciting. We took a long road trip to take the kids to see both sets of grandparents and my sister in Philadelphia. My son keeps asking when we’re going back. I’m sure that being showered with far more presents than any kid actually needs has a lot to do with that. It’s probably also really nice to have a good stretch of time when Mommy isn’t glued to her computer. Guilt? Yeah, I have a lot of that and some to spare. While in TN visiting my parents, we took our kids to a lovely local playground where I managed to get the worst ankle sprain of my life. There is NO logical reason for spraining my ankle where I did. I didn’t step into a hole. The ground was flat and stable. All I did was step off a small platform, a step down of about 8 inches. My ankle just buckled underneath me.

I am proud that I had the fortitude not to scream out the various conjugations of the f-bomb since there was a crowd of small children running around and having a great time. I sat down, blinded by pain, and waited for about two minutes, breathing deeply, until I could calmly call Dan over and tell him I had managed to injure myself for no reason whatsoever. I limped to the car and somehow into my parents house. I was not able to walk on my ankle for the rest of the day. I had to use a pair of my Dad’s old crutches to get around. My sister, the physical therapist, said the healing process is about two to three months for a sprain this bad. I can walk on it now, two weeks later, but it still hurts and feels weak and unstable when it is not wrapped in an Ace bandage and ankle brace. To say the least, my first week back to work was strictly work from home.

Two days after we got home, we went shopping for groceries. On this fateful trip, our son fell out of a shopping cart and busted one of his front baby teeth. It was too damaged to salvage, so it had to be pulled. Yep, we are those parents. The parents who let their kid ride in the back of a shopping cart against all recommendations and warnings posted on the carts themselves as well as the warnings given by the dentists and doctors who have to treat kids who are injured by falling out of these carts every day. Heathcliff will be The Kid Who Is Missing a Tooth for three or four years before his permanent tooth comes in. He will also be The Kid Who Is Never Allowed to Ride In The Back Of A Shopping Cart Ever Again.

In the midst all this holiday excitement and the handling of physical injuries, I did not have much time to work on Brixen. Shortly before we left on the Big Christmas Road Trip, I converted more of the code base over to C# and discovered to my disappointment that the decorator pattern in the Java code base is not possible in C#. Extension methods cannot satisfy the contract of an interface. And since C# does not have the equivalent of default interface methods, I am basically shit out of luck with the decorator pattern in C#. Therefore… this codebase will be a lot more verbose because classes needed to implement multiple interfaces will have to inherit from an implementation of one of them and then provide implementations for the methods of all of the rest of them. So, that kind of sucks.

One of the nice benefits of doing this translation is that it brought to my attention that I had made a bad design choice for the ControllableBean and its associated builder. Reflection is in powerful tool, but it should be used sparingly. Here is the original source code for ControllableBean:

So, this is a total abuse of reflection. The two-arg setters for adding new controls should not take a control name and a class type for the bean. They should take a name for the control and an instance of the bean. This is a much more logical and simpler design and I feel like a dolt for not realizing this from the beginning. Here is the new and improved version of ControllableBean:

This is much better. This interface is easier to implement and easier to understand. These code changes will be uploaded to GitHub soon. Meanwhile, we’ll just keep this little over-complication a secret between ourselves, won’t we?

In other news, it seems that my company is finally going to allow us to use Sauce Labs. I honestly did not think that anything would come of the research into the cost of their services that I was asked to do a couple months ago. However, it seems that we are doing a trial run with them soon and there is a manager assigned to the task of driving it now. I am so excited I can barely contain myself. Having access to some decent infrastructure to run large Selenium suites would be a sea change for my team. It seems that my employer just might have finally taken a first step down the road to building Good Automation.

Share This:

Long Time, No Post

My translation of the existing Java codebase for Brixen into C# continues to slowly move forward, hampered mostly by long hours for my job and the inevitable craziness of the holiday season. I have not yet encountered anything that I have been unable to duplicate in C#. I have learned how to implement extension methods and how to use generics in C# which is awesome.

I am struggling to replace an old smoke test suite for the product I support before I leave for Christmas vacation. I feel like every victory I have is rewarded with a new and difficult obstacle. Every time I successfully clear one hurdle and need to take the test suite to the next level, there is some new, difficult problem to solve that takes a week to deal with. Meanwhile, the QA Director keeps asking, “Where is that sweet sweet automation you promised us!” It’s hard to explain to people who don’t code the difficulties and challenges of re-tooling something to get around things like defects in the open source tools you’re using, or building out infrastructure to support things like configurable suite options and test data feeding. It always sounds like I’m making excuses for my pitiful lack of amazing progress in producing Teh Automation Suite of Amazingness and Wow-dom.

One thing that annoys the shit of me is that it seems that all prior progress I have made is forgotten as soon as a week goes by without new test cases getting automated. It doesn’t matter that I managed to build infrastructure that allows me to execute the exiting test cases across multiple scenarios as opposed to one. It doesn’t matter I had to stop and produce something for the test automation framework that we are trying to shove down the throats of the other business units. It doesn’t matter that I had to implement a work around for a TestNG defect. All that matters is that new test cases were not automated that week. The fact that I have automated almost 75 percent of the test cases covered by the old test suite I am replacing in addition to automating test cases that the old suite didn’t cover is quickly forgotten.

The QA director has taken to the habit of stopping by my desk and publicly ‘joking’ that I emailed him the night before to tell him that I was already done with the smoke test. Or that I told him I would be done early. Nagging that is disguised as good-natured teasing is more annoying that direct nagging could ever be. Seriously, it just makes me want to spend the next hour Christmas shopping on Amazon for my kids out of spite. The agreed upon deadline for finishing the smoke test replacement effort was still TWO WEEKS AWAY when the nagging began. It doesn’t help that we have all been told to expect lower bonuses this year and that my bonus is riding largely upon the successful completion of this project before I leave on vacation. It isn’t worth working the kind of hours I do to put up with that crap. Plus, all this overtime and stress is getting in the way of moving forward with Brixen which is far more interesting and fun to work on.

Another giant pain in my ass is that the principal SDET and Architect of the automation framework we are trying to shove down the throats of the other business units tried to quietly sneak in some page objects from her old framework into the new one because her junior engineer didn’t want to spend 10 minutes asking me some questions about how to follow the far superior approach I busted my ass to develop. Instead of making a real effort to convert to the new framework, he just wanted to be lazy and just do it the way he had gotten used to doing it. I tried to point out the irony of our effort to make the other business units switch over to our way of doing things while allowing an engineer on our team to avoid doing exactly that, but the principal SDET played dumb and pretended that my point was totally incomprehensible. This lead to a demand for a code review of the core classes in the page object API by the principal SDET.

I wrote a few Wiki instructions for how to use the core classes. For example usages of the API, I used the page objects I had built for the customer portal to support my automation. At one time in the recent past, I had advocated that the API as well as the page objects built with it should both be part of the framework, but the principal SDET insisted that only the API should be in it. So, at her insistence, I moved them out of the framework project. During the code review, the members of the West Coast team who were taking part interrupted me as I was in the process of explaining some of the examples on the Wiki page to ask, “This LoginPage class you show here…. where is it?” So, we had an unscheduled discussion about the new features they wanted in the the LoginPage class and the other page object classes for navigating through the customer portal. I would feel more smugly satisfied if I had not just signed myself up for even more work.

Share This:

Fumbling Around Like a Total N00b: Translating Brixen from Java to C#

I spent a week scratching my head over failed unit tests that were ultimately the result of jackass n00b mistakes, and sadly, they were not C# n00b mistakes, but Coding 101 n00b mistakes like not checking for null and failing to actually set the value of a property after validating the parameter for its setter method. Oh, and leaving off the parentheses for a method call. Thankfully, I didn’t turn to Stack Overflow for help. My reputation would have taken a severe nosedive for requesting help with such embarrassingly basic bugs. And this, my friends, is why you should write unit tests. It saves you from checking dumbass Coding 101 mistakes like this into source control where they can be found by your co-workers who might be tempted to slowly freeze you out from the important and rewarding work because they just can’t trust you to write a decent for-loop without a user’s manual at your side.

I still haven’t figured out how to write an integrated build script for Brixen that would compile, test and deploy both brixen-java and brixen-dotnet. I did however, take the time to learn some basic Nunit framework usage so that I could actually write some unit tests. I also tried to integrate Nlog logging into the unit tests, but for some reason, the logging statements don’t get output to the console in Xamarin Studio, so I took it out. I think I need to try this on a Windows system with Visual Studio.

When I started coding, I realized I had no idea how a standard .NET project should be organized. I went in search of a guide and found that finding such a thing was not all that easy. It’s as if there is this pervasive assumption in the .NET coding community that you should just know how to structure a .NET project by osmosis. With Maven, there is a well-documented project structure and there’s generally no question where something should live. Java enforces a directory structure convention for packages which does not exist in the C# world. YouTube came to my rescue in the form of a short, awesome video tutorial where the creator of the video explained that these things are in fact often hard to figure out because they are not explicitly documented by Microsoft.

After basically learning the basics of a totally different tool chain, I finally got something that I could check into the Brixen GitHub repo that I was not ashamed to call my own. So far, I’ve only translated a handful of the state beans into C#, but things should move faster now that I have surmounted some of the learning curve. The code is definitely going to be more verbose than the Java version due to the lack of a tool like Lombok. I have to write implementations of ToString(), GetHashChode() and Equals(Some Object) which is tedious. In Java, I can just throw a couple annotations on a class and these methods are auto-generated at compile time by Lombok. I’ve updated the corresponding Java classes too. In the source code I presented at the Selenium conference, I did not do any parameter validation for the setter methods because I wanted to cut down on the sheer volume of code I had to present. I am now adding back in the parameter validation that I cut out because it’s just a good idea to validate parameters. So, the Java code is more verbose than the code from my presentation.

The Decorator translation is a little harder to pull off in C# because I have to use extension methods to produce something like the default method implementations that Java 8 allows, but at least, thankfully, it is possible to do. I treated myself to the pleasure of reading explanations of why Java 8 was just totally wrong for allowing this atrocity into the language because it violates the very definition of an interface. This may be true, but default interface methods are just astoundingly convenient in ways that justifies the atrocity in my opinion.

Share This:

Learning a Foreign Language: Translating Brixen From Java to C#

I started translating the existing codebase for Brixen from Java into C#. I mistakenly thought this would be a quick and easy task because the syntax of C# appeared to be so similar to Java. Syntax Schmintax. I didn’t realize how fundamentally Java had arranged my thinking around How Development Works. My first jolt was discovering how bonkers I was for thinking that it would be a breeze to do this. I was thinking that all I would need to do is install a plugin for IntelliJ and I would be golden. If I couldn’t do that, surely I could just use Eclipse. Fast forward two weeks, skip over a lot of cursing and forehead slapping, and I am using Xamarin Studio. It took a while, but I came around to accepting that you just don’t mix C# and Java in the same IDE. It’s. Just. Not. Done. I also eventually accepted that C# isn’t platform independent, and developing in C# on a Mac is kind of whack.

My second more unpleasant jolt was that Maven doesn’t support C#. This one was a lot harder to accept. I thought it would just be a matter of adding some new dependencies in the POM for Brixen, adding a build plugin or two and I’d be good to go. I would have brixen-java and brixen-dotnet playing all nicely together and all I needed to do is type ‘mvn install’ and shit would just work. It was really hard, but I finally accepted that this isn’t how it’s going to be. I still have no idea how to do the build and deploy thing for the C# packages, but I decided to defer that task while I try to learn the C# language.

There’s no Lombok for C#, but there are these things called properties which sort of do the same thing. The naming conventions in C# are whack. Seriously?! PASCAL IS SO OVER! Interfaces can’t have fields?! The languages are similar enough on the surface that it’s not too difficult to translate from one to the other, but they are different enough that I am regularly irritated and pissed off in some fashion. It’s like a rash that isn’t bad enough to make you go see a doctor, but still annoying enough that you really really want a steroid shot JUST TO MAKE IT STOP ITCHING. I just have to say to all you people who love C# — WHY? Why do you love it?

Share This:

Brixen Decorators: What’s Changed

The basic concept of the decorators hasn’t changed. There are just more of them. I have added decorators for state beans, configuration beans and builders in addition to the decorators for the component implementations. The decorators help reduce boilerplate code by using a new feature introduced in Java 8: default interface methods. A class can implement numerous interfaces, but extend only one class. Prior to Java 8, this meant implementing the same methods over and over again in different classes extending a particular interface. After Java 8 however, a decorator interface can extend another interface and provide default method implementations for the interface it extends.

Here is an example of the PolleableBeanDecorator, which provides default method implementations for the methods required by PolleableBean:

The decorator defers all the PolleableBean method calls to the default PolleableBean implementation — PolleableBeanImpl. This is achieved by requiring a ‘provider’ for an internal reference to a PolleableBeanImpl instance. So any class which implements PolleableBeanDecorator needs to define an accessor method for this provider. Let’s have a look at the provider for a state bean:

I didn’t want to have a method in a decorator interface that would return a reference to the internal state bean itself because that would break encapsulation. So, I came up with the idea of a ‘provider’ which would give protected access to this internal state bean reference so that only a sub-class or a class within the same package as the provider would be able to access the internal state bean reference. The packaging structure I chose allows only the provider and its sub-classes, the decorator and other classes in their package to access the provider’s internal state bean reference.

Here is an example of a state bean which extends PolleableBeanDecorator:

DynamicControllableBean is a state bean for specifying a page object that contains one or more web controls which needs to be polled for state change of some kind, usually after an interaction with one of its controls. A drop down menu, for example, would need to be polled after interacting with the control that expands or collapses it to determine if the menu has expanded or collapsed as expected. The default implementation of DynamicControllableBean can only extend a single class, so its parent is ControllableBeanImpl.

It would be a drag to have to provide implementations for the methods required by PolleableBean which are exactly the same as the implementations provided in PolleableBeanImpl. By implementing the PolleableBeanDecorator interface, DynamicControllableBeanImpl can satisfy all the requirements of PolleableBean by providing only an accessor to a LoadableBeanProvider that wraps an instance of PolleableBeanImpl. Lombok helps reduce the amount of source code even more because the provider field only has to be annotated with the Getter annotation.

The decorators for the configuration beans operate in the same way. Here is the PolleableConfigDecorator and the provider for a configuration bean:

And here is DynamicControllableConfigImpl, a configuration bean which implements PolleableConfigDecorator:

Decorators for the builders was a bit trickier to pull off, but I managed to find a way. Here is the PolleableBuilderDecorator:

And AbstractDynamicControllableBuilder, which implements it:

This decorator implementation works by declaring a provider which wraps the builder implementing the decorator. The same state bean must encapsulate all the state for the component, so declaring a builder with a separate state bean instance wouldn’t work.

The decorators for the components haven’t changed, so I won’t post any examples here since it would just duplicate what I presented at the conference. The source code for Brixen is here.

Share This:

Brixen Configuration Beans: What’s Changed

The changes in the configuration bean package are mirrored largely by the changes in the state beans and the builders. The other change is that I added JSON type information to all of the configuration bean interfaces. When I originally conceived of the configuration bean idea, I foolishly didn’t consider the possibility that some configuration beans may contain other configuration beans as fields. So, I only added the type information to the LoadableConfig bean. Without this type information, Jackson cannot properly deserialize polymorphic types.

The other change is that LoadableConfig allows the definition of custom properties, through JsonAnyGetter and JsonAnySetter methods. It is entirely conceivable that one might want to define a configuration option for a page object which doesn’t have general significance to a class of page objects, but which is important for a specific context:

The ControllableConfig is the most significant new addition. This configuration bean is for defining the dynamically configurable options for a page object which contains web controls. This configuration also encapsulates the configurable options for each one of its controls:

There is a marker interface for a dynamic Controllable that needs to be polled on intervals for a state change via a FluentWait:

Here is an example of what the configuration source for a ControllableConfig would look like:

In the same fashion as the state bean and builders, there is a marker interface that is parent to all the control configuration beans:

The marker interface for a click control configuration bean:

It extends ClickableConfig which is a configuration bean for a wider class of clickable page objects besides controls:

The configuration bean for a hover control:

The configuration bean for a hover and click control:

And that’s a wrap for the changes in the configuration beans. The source for Brixen is available here.

Share This:

Brixen Builders: What’s Changed

One of the awkward things about the original version of the API is how data from a page object’s JSON configuration source is retrieved and handled. I wanted to do something that was more elegant and less cumbersome than the multistep process of the original:

  1. Querying the service for a configuration
  2. Determining if a particular dynamically configurable option is defined in the configuration
  3. Determining if the value assigned to the option is null
  4. If the value is not null, then retrieving its value from the Optional that wraps in the configuration bean and setting that field for the page object through its builder

All of the the builder interfaces now overload all the methods that specify a page object’s dynamically configurable options. One version of the method takes a value for the field, and the other takes a configuration bean. The builder implementations take care of all the steps listed above save the first step. They also handle the case where the configuration bean is null. All the client class has to do is query the configuration service for the page object’s configuration by String ID and pass the result to the builder. If there is no configuration defined for the current environment under test, then the service will return null. If the configuration bean which is then passed to the builder is null, the builder will do nothing with the bean and leave the default value for that field in the page object’s state bean unchanged.

Let’s look at a couple of examples. The LoadableBuilder, a builder for a basic page object, and PolleableBuilder, a builder for a dynamic page object which needs to be polled on intervals for a state change via a FluentWait, are basically unchanged since the conference except for the new methods which take a configuration bean.

The default implementations of the new setter methods do all the work of checking and retrieving the data from the configuration bean which was previously the responsibility of the class building the object:

The other big change is related to the total refactoring of how web controls and the page objects that contain them are specified and built. Each of the three types of controls described in this post has a builder, but there is also a builder for a page object containing controls which has methods for specifying the controls.

The marker interface for a control builder:

The marker interface for a click control builder:

It extends ClickableBuilder which is a builder for a wider class of clickable page objects besides controls:

The builder for a hover control:

And finally, the builder for a hover and click control:

There is a _lot_ of duplicated code for the hover control and hover and click control, just as is the case for their state beans, which I acknowledged in my post about the changes in the state bean package. For now, I don’t see a good reason for extracting the common behavior into a parent interface for both of them to extend because the parent interface wouldn’t be reusable in other contexts. It’s a wart on the butt of this API, but I think I can live with it.

The interface for the builder of a page object which contains one or more web controls has a lot of syntactic sugar that allows you to build the whole page object, complete with all its controls if you don’t want to use the individual builders for the controls themselves. Each control is associated with a String ID that must be unique (which should go without saying, but I couldn’t help myself):

Share This: