Contrarian Musings
-
What Legos Teaches Us About REST API Testing
My son loves Legos. He is continually fascinated about the ways he can use and reuse various Lego blocks to build different kinds of towers and other edifices. He also likes to use the same larger Lego blocks as a foundation for a multitude of different towers. Why should REST API testing be any different? Herein, I refer to two main patterns for REST API testing:
- Classes in your REST API test infrastructure should reflect a Separation of Concerns . Each class is like a Lego block that contributes its own particular set of functionality.
- Features for REST API performance testing should be tightly integrated with your test infrastructure from the beginning and utilize the same foundation upon which the functional tests are built.
This is best explained by the code below. This code is in Groovy and represents these patterns but the patterns are applicable across languages. One functional test method and one performance test method is shown.
Regarding pattern #1, like building blocks that fit nicely together, each class is responsible for its own “separate concern”. When we separate out the behavior as shown, we prevent ourselves from repeating code needlessly across different tests. This leads to the tests having VERY FEW lines of code and being VERY READABLE.
Regarding pattern #2, there are many different types of performance testing but one thing this type of testing commonly necessitates is concurrent connections. This is often overlooked when test infrastructure is built around single request-response scenarios or utilizes some off-the-shelf tool that has a proprietary language that only one or a few on a team will understand. (As a side note here, I also strongly recommend the http client utilize non-blocking connections so that it isn’t using one thread per connection and thereby unable to scale to higher concurrency levels due to client resources skewing metrics.) Why not use the same code (read: Lego blocks) that was the foundation for the functional tests and apply that to the performance tests as well? Doing so nicely applies the DRY Principle to your test infrastructure. This pattern allows for continuously running performance tests that can be created quickly and which can provide metrics that can be captured in a database for reporting and trending purposes.
-
The Power of Java 8 Lambdas with Generics
One of the nice things I like about the new Java 8 lambdas is that I can encapsulate common code inside a method. So if code inside the doPrintln() method is an algorithm or a test that needs to call common code multiple times as represented by the myFunc1 lambda, we don’t need to bring that logic outside the method by creating a separate private method. We can maintain DRY (“do not repeat yourself”) code by using a lambda.
By combining the power of generics and varargs, I’m able to have a lambda take a variable number of arguments of any type. This reminds me a lot of some Scala code I’ve seen and used. I’ve also done something similar using C# func delegates.
I think larger methods with lambdas inside are a better design practice and increase readability. When your eyes come upon a class for the first time, the private methods don’t cloud things by requiring one to figure out how many other methods are using the private one. Yes, a few clicks in an IDE will tell you, but this is one less step to get you there. This is an excellent way to implement method or function cohesion.
-
Innovation Day at Work!
#innovation day — what fun! It has been a while since I’ve had a chance to blog. That is because I’ve been heads-down at a new job as Principal Quality Engineer working on the backend automation architecture and automation tests for our webservices team. However, I did want to blog about Innovation Day here at Constant Contact. It was great. In fact, there are many great things about working for a company that has an Innovation Day. My idea was a mashup between Constant Contact and a 3rd party API and the team we had really helped to flush out the idea and bring the demo to fruition. We had a short presentation piece and our demo was set up along with those of others in a science-fair like setup (see picture below). It was a lot of work but a lot of fun as well. I staged our demo on Heroku (first time using it) and brushed up on JSPs and servlets and had a chance to touch different parts of our products that I wasn’t hitherto familiar with. The third-party API was really helpful in getting us access to their sandbox for our API integration to work. Innovation takes work and it makes sense for a company to set a block of time aside for software engineers to unleash their creativity. I know I’m better for it!
-
Enjoying #Akka With #Java
I was extremely surprised at how easy it was to get Akka 2.0 up with Java. I used typed actors with futures. Why would I ever go back to shared state threading and deal with lower level constructs such as synchronization and locks? I still have lots of Akka goodness to learn though.
-
Asynchronous Scala Rest Client with Spray
#scala #spraycc #rest
One of the things I really enjoyed at the NE Scala Symposium this past week was getting the Spray Rest Client going during the hacking sessions. Below is a snippet of this code. I also integrated it into ScalaTest. The hard part was getting it integrated with maven since the canned spray examples all use the Scala SBT build tool. But once I got it up and running in Intellij IDEA, it was great! The nice thing about spray is that it is 100% asynchronous — it is very, very fast. In fact, someone at the conference from another company compared it to other Java asynchronous rest frameworks and found this to be the fastest.
I can’t wait until the next version of spray which is due out very soon. It will have support for Akka 2.0 and SSL. All of the related code is at my github here.
-
New Amazon Review of my Test Automation book
#in #agiletesting #sqa
I’m very excited that the Experiences in Test Automation book in which I have contributed a case study chapter received its first glowing and detailed review by a reader on amazon.
-
Using Squeryl and ScalaTest to connect with Postgres
It wasn’t too hard to get a ScalaTest going that makes a database connection using Squeryl (a Scala ORM). I was able to do a select statement against a postgres database and get some data out.
This select statement above assumes the sql below is in the running database. This allows the test to print “jason” if all is running correctly.
All the code can be found on github here
-
Integrating ScalaTest with TestNG and Maven
I totally trashed my Intellij installation by trying to manually install a Scala plugin I think because I only brought in one of the many needed jars. Once I got Intellij 11 up and running with the Scala plugin by installing it the right way, I found that it is awesome. I now have a demo of using ScalaTest with Maven and TestNG at my git repo here . You’ll see from the readme in the repo that the whole demo is runnable by a simple “mvn test”. One of the gotchas is extending a Java base class in Scala and still needing an import statement for said Java class in the Scala class.
Here is the ScalaTest TestNG Test Class
-
Performance Testing
#sqa #in
It is a nice feeling of satisfaction today! Nothing has been able to survive my multithreaded C# SOAP client test based on TPL (Task Parallel Library). But we have a great DBA that can look at my database trace file to pinpoint the issues. Score for my performance testing setup!
