Are you familiar with DotNetRocks? If not, either you are not a .NET Developer, or you’re just not cool. Just kidding. Here is my summary of a podcast I did with DotNetRocks on Testing in the Cloud.
DotNetRocks is not just a resource for developers on the Microsoft Stack, it’s a community and often the topic of conversation in .NET development circles. I was privileged to be invited by Richard Campbell and Carl Franklin to talk about the topic of Testing your Code in the Cloud. You can find the episode here.
I must admit, given the production quality of all of their shows, I was a bit intimidated, which is strange for me to say. But it was a blast. The biggest thing that stood out to me after the conversation was:
How you develop & how you test is even more tied to the types of applications you are building.
In the past the type of application you were building was directly related to the language and IDE you used. But today, the language and IDE have almost nothing to do with it – the process of coding does. Let me explain.
For example in 2008 if I was a C# developer who used Visual Studio, then I was writing a Client-side Win32 app. You could almost assume the applications being developed were web applications, mobile applications, or business intelligence/bigdata database-driven applications, but you couldn’t assume the IDE or language. Now, in 2013, neither the IDE you use nor the programming language gives you hints about which of these three I’m creating. Because with the exception of Objective C, and writing applications for IBM ( HA! ), you can’t assume the types of applications being written by the language or IDE used.
WHY does this matter? Because in the world of application testing, it isn’t so straight forward what tools you use, and how you use them. In 2008, you could point to the proper unit testing tool for your Win32 app. But today, not only are the choices endless, they all work to some extent with your application. And really the effort to build a testing process has a similar complexity to the application you are building.
During the podcast you will hear a small portion where it’s not entirely clear if we were talking about web application development or line-of-business applications.
The bottom line, testing your application in the cloud = good. The reason it is good is:
- Developers and QA teams can get environments faster
- The elasticity of the cloud allows developers to do special burst testing
- The repeatability of virtualization in the cloud ( Snapshots ) allows developers to replicate environments and grant access to them rapidly
- And … because it is in the cloud, and it is separate from your production and on-prem environments, the risk of testing new and interesting things is lower and developers can do more with less risk
BUT “Testing in the Cloud” is not one-size-fits-all, it’s not even any size fits any. Each configuration of development and its associated testing environments is unique to the dev team, and unique to the application being built. Which almost means, that unless you are using the cloud, with its infinite flexibility, you are killing yourself internally adapting existing systems to catch up with modern Application Lifecycle Management processes such as continuous deployment and integration. Or more likely, without the cloud, you will not embrace the modern ways to code, because it’s just too hard and risky.
The problem gets even more complex when your organization has a backend team, doing more traditional development on services, and client applications, that build a platform for both a web development and a mobile development team. All of these teams are different, but for the consumer of the solution, it is the same product. So you are not only finding a way to improve how just one of these dev units tests, but all three together.
The podcast also highlighted the question of when do you choose IaaS over PaaS or do you? In hybrid scenarios such as the one described above where you combine the backend team with a mobile dev team, you don’t really have a choice. The backend team will need a Virtual Machine ( VM ). You can choose who gets access to the IaaS, but in this case your database developer is building the PaaS for the mobile developers, and he/she needs infrastructure.
There is an argument to be had, that in the world of testing, you should not be limited to how deep you can go to unravel a problem. Even when consuming a PaaS service, the web application or the mobile application will be pointing to some web server, and that web server is on some sort of infrastructure. There will be a scenario when the configuration on that VM directly impacts the performance ( more common ), or creates bugs.
PaaS in my opinion today is still just a component of your application, or resources you are consuming, but unless you have your own datacenter, the heart of the application is on some infrastructure somewhere.
The podcast went on to define all sorts of considerations you have in testing your application. There are many. Not only that, the choices in all the various automated testing tools that you can use with your cloud testing environment are far too many to count or know in detail. But the good news is that if you have a Cloud testing environment setup, it should give you the latitude to use whatever you wish be it LogiGear, Telerik, DevExpress, Selenium, Xamarin, you name it.
Take a listen to the podcast, and let me know what you think about the world of application testing.
