Testing in Production

This is a topic that always draws some great responses when discussed where I work. Do you Test on your production systems?

I always come to the same conclusion on this one. Why wouldn’t you want to test in production? I know, I know. Your system is too “special” or “secure” or “regulated” or whatever to be able to test in production. So what are you going to do? Let your customers test it for you? Throw the code over the wall to the people that matter most and hope that it works for them? Take the chance that your customer will just understand when the house of cards comes crashing down in a burning heap of lame?

To those that say it just can’t be done, I say that maybe your system is just lacking testability – you haven’t built it right. To me a testable system is one that has a great handle on control and is inherently observable. If you can’t control and observe the software, you are dead out of the gate. Often, if you solve the control and observation issue, you will find a system that you can test in production – because you engineered it to be easy to do so in any environment.

So take a look at your systems and ask yourself if there are any measures you can take to affect the testability of your system in a way that would lead you to be able to test your system in production. Face it, no matter how you try, your QA systems will never be the same as your production systems. The data, traffic, configurations, scale, timing, etc. will just never match well enough that the tests you run in those environments will catch everything. Change control, make it observable and make sure your system works in production before your customer does it for you!

Centralized vs. Federated Integration Test in the Enterprise

I have been working on the question of federated vs. centralized integration test practices in the enterprise lately. As I have done some research into the topic, I have found that few resources are around on the topic. While some white papers exist, it appears that most companies are in the federated camp: relying on individual divisions to create their own integration test strategies – even when there are many ties among their applications that could benefit from a centralized approach.

Some companies like Google have extremely large tests that involve many applications, and even automate them to some extent. Most though, including the ones that I have worked for, spend time testing software from within their respective silos in an effort to protect their own. Each of these groups tend to create and maintain redundant sets of tests that cover their application needs.

The problem is that many of these needs are the needs of many of the other groups and a great deal of redundant and poorly performing tests are written. Every group creates a test to “create a user and password” for instance. Each is created in their silo and when the functionality changes, each breaks in their own way. Tests that perform things as trivial as this, and of course much more elaborate are created all of the time that could be shared.

Creating a centralized integration test group may be able to fix this redundancy issue and help protect production quality as you do so. Sharing resources, test data management, and testing know how might be a way to create a group that solves the issue of poor communication across your organization when it comes to system integration test. This one set of testers will help build the “moat” that protects your production castle from impending doom.

Android Shared Preferences Backed Up

I have been looking around for some way to back up the preferences in my Android app – just a simple serialization of the SharedPreferences object. Here are some code snips from my backup object that allowed me to get the job done:

private void importSharedPreferences()
  SharedPreferences prefs = getSharedPreferences(PREFS_NAME, 0);
  File myPath = new File(EXPORT_FILE_PATH);
  File myFile = new File(myPath, PREFS_FILE_NAME);
		BufferedReader i = new BufferedReader(new InputStreamReader(new FileInputStream(EXPORT_FILE_PATH + PREFS_FILE_NAME), "UTF8"));
		String line;

		while ((line = i.readLine()) != null)
				String[] pair = line.split(":");

				SharedPreferences.Editor prefEdit = prefs.edit();

					prefEdit.putBoolean(pair[0], Boolean.parseBoolean(pair[1]));
				else if(pair[2].indexOf("Integer")>-1)
					prefEdit.putInt(pair[0], Integer.parseInt(pair[1]));
				else if(pair[2].indexOf("Float")>-1)
					prefEdit.putFloat(pair[0], Float.parseFloat(pair[1]));
				else if(pair[2].indexOf("Long")>-1)
					prefEdit.putLong(pair[0], Long.parseLong(pair[1]));
				else if(pair[2].indexOf("String")>-1)
					prefEdit.putString(pair[0], pair[1]);

public void exportSharedPreferences()
    SharedPreferences prefs = getSharedPreferences(PREFS_NAME, 0);

    File myPath = new File(EXPORT_FILE_PATH);
    File myFile = new File(myPath, PREFS_FILE_NAME);

    FileWriter fw = new FileWriter(myFile);
    PrintWriter pw = new PrintWriter(fw);

    Map<String,?> prefsMap = prefs.getAll();

    for(Map.Entry<String,?> entry : prefsMap.entrySet())
    		pw.println(entry.getKey() + ":" + entry.getValue().toString() + ":" + entry.getValue().getClass());


I removed all of the error handling and might have messed up the formatting a bit, but you get the idea. Also, I plan on moving the serialization to a XML format in the next few days instead of the janky colon-separated bit. Hope this is helpful to you!

Exporting MS SQL Schema

I seem to forget this one, though I have to do it now and then, so I thought I would share this in a post. Somehow I always find myself digging into “Script Database As” instead of the much less appropriately named “Tasks” – which is where you want to be. If you want to export the schema of your MS SQL database, here is what you do:

  1. Open the Microsoft SQL Server Management Studio, and connect to the database
  2. Expand the Databases node, and right click on the database you want to export the schema for
  3. Choose “Tasks” (in 2005 “All Tasks”) then “Generate Scripts”
  4. Navigate through the wizard choosing your database
  5. You can choose “Script all objects in the selected database” on the “Select Database” page, or hit next and choose the individual objects on the following screens like Options, Schema, Tables, and Users
  6. Finally you will find the schema and tables to select
  7. On the last page of the wizard you can choose to output the schema to file, clipboard or to a new query window

Hope you find that useful!

C# Path of dll vs. Application path vs. EntryAssembly path vs. Form path

OK, I have stumbled on this one a few times so I thought I would blog it up so that I had a place to come and find the answer. The problem most recently was an application I wrote that I use as a command line tool, but other times as a class that hits a constructor. Either way a property file is needed, and depending on the way I call it I had trouble finding the path to the config…

The problem is, when you use Microsoft Visual Studio to launch the debugger, the Application.StartupPath can’t be relied upon, as it points to the Studio directory. At run time it might work, but not for the case I had in mind where I needed to know where the DLL itself was.

So you can use this:


But that is for a windows form startup path – useful, but not for me.

This will give you the directory the app started in (but again, it may be a Visual Studio directory if debugging):


And this will give you the process executable in the default application domain, or the first executable that was executed by AppDomain.ExecuteAssembly – again, not what I needed:


Finally, the winner is (and look closely – GetExecutingAssembly vs. GetEntryAssembly)


This snip allowed me to find the directory where the DLL was currently executing, and thus the config that sits next to it. So many ways to get at run-time information! Hope that helps you!!

Google Android Market VS. Amazon Appstore

There are plenty of 2nd party App-Store wanna-be’s out there like SlideMe.org, AndroLib, AndAppStore and others that have tried hard to crack the Google Android Market gold mine, but have had only mild success. While Google rested on their “we own it” laurels, and did little to bring the Android Market to the public in bigger ways, monsters like Amazon now loom in the background – threatening t o bring real web development and internet sales skills to the table.

Google may have the lions share of the app sales game at the moment in the Android space, but are they moving too slow to lead?  Recently the search giant introduced a new web presence for the Android Store that allowed online browsing, and push to phone – something sorely missing from the Android experience, but possibly too little too late.Google needs to step up their game here I think, or the doors might be open exposing the castle keep here.

The thing with smart-phones and app stores is that they need to be sexy! You have 10 minutes to kill, so you turn on your phone, hoping to be amused, informed, amazed. Google’s less is more search interface, while perfect for the desktop experience, doesn’t fly here.  The current Android Market web experience is like it came from the same department – sans sex. Google needs to bring in some designers and marketers that know how to make me A) open their app store when I have 10 minutes, and B) be excited to be there and get new stuff.

Amazon has recently moved into Google’s space with their Appstore.  Having looked at it from the beginning, months prior to the release, I can say that they have really come a long way.  In fact, I think maybe they have even one-upped the big G’s gold standard. They have editors (that are used to selling stuff!!) writing content for app descriptions, and have an app submission process that is getting pretty sweet. Their one click purchase system makes it a breeze to get that new app, and their Appstore is fresh and feels right.

Look for more competition in this space, as there is plenty of money to be made here.  For now, these two behemoths have the dance floor and while it may not yet be even money, look for Amazon to do everything in it’s power to be in mobile as a formidable leader.

TFS Instance Appears Read Only Until Mapped

OK, I’ve run into this one with Microsoft’s TFS server a few times so i thought I would talk about it to help me remember it.  MS has come a long way with their version control software, with TFS light years ahead of some of the old versions of Visual Source Safe, but there are always “duh” moments that a co-worker helped me to remember today.

At my job we use a single TFS server and have instances that are created for various groups in the company.  If you want access to another instance you open a ticket with the IT folks to give you permission to get at it.  There are 2 types of access, read only, and an “Advanced” developer mode that gives you the keys to the candy store.

After my request for total control of the TFS repository was completed, I went into Team Explorer and then into Source Control and saw the new instance ready to go.  I wanted to create a directory and start adding some code to the repository but noticed that by right clicking “New Folder” was grayed out.  All I saw was “Refresh” and “Add items to Folder”.  My security request had surely been mishandled I thought (or less likely I had asked for the wrong access 😉 ).  I opened another ticket and got – “You already have “Advanced” stupid”.

Well, a few minutes scratching my head had me stumped and wondering what to do.  I checked with the owner of the repository and he said I should be good to go as long as I have advanced.  Oh, and have it mapped correctly.  Mapping!!!  This is the key!  Just because the repository is shown in your Source Control Explorer, until you have it mapped you might as well only have read access.  So I right click on the instance, choose “Map to Local Folder” and enter the path that I want to map it to and POW! – we have liftoff!  I now have a correctly mapped folder that I can create folders and add content to my hearts content.  On to the coding!

Google Changes Android Market Payout to Monthly

Didn’t see this one coming, and I usually have my ear to the rail on the Android front… So late last year Google changed the TOS on the Android Market and changed the payout schedule from 2 days to monthly. I didn’t notice a thing, until I read someone on twitter complaining. Sure enough, I looked and today was the first day my Android account received nothing.

So it’s not like I’m living off the cash flow, I do it on the side and don’t depend on my app sales for day to day expenses or anything. But the thing that bugs me is that it just adds another question mark to the “Do no evil” Google checklist. I mean really, it’s not exactly evil, I can even understand why – it has to cost a fortune to wire all that cash around every day not to mention the hassle of keeping it all going.

But the thing is, that trickle of cash was just another way of saying “We are Google, we don’t hold on to your money” which just feels like the opposite of evil. Now they join the other app stores and pile up our money, gaining interest while they make us wait. Maybe that is evil.

The other day I saw that mobile ads would hit a billion dollars for Google this year. The projections I’ve seen for Rim, iOS, and Symbian look pretty dismal compared to the 2+ year Android skyrocket. I call on Google to do less evil. Maybe they should lower their 70/30 cut and go 90/10 or something to show that they know that developers drive those numbers in the end.

Redirect a Site to Sub-directory with a Little aspx code snip

So my problem was I installed DotNetNuke on a web host provider, but they forced you to put the install into a subdirectory.  I needed a way to permanently redirect anything that came in to http://original.com to http://original.com/new.  Turns out that the following little code snip does the trick, all without losing your search engine ranking – double score!  I saved this in the root of the (ASP.net) site as Default.aspx

<script language=”c#” runat=”server”>
private void Page_Load(object sender, System.EventArgs e)
Response.Status = “301 Moved Permanently”;

Android Layout findViewById Returns Null

Every once in a while you run across a coding issue that has occurred in the past but you can’t remember the resolution. Tonight is one of those times and the issue was an Android Layout one.

I had a layout xml file with the following id on a TextView:


In the OnCreate() method I set the content view:


And then went to get the TextView as such:

TextView foo = (TextView) this.findViewById(R.id.foo);

The problem is, foo is always null.

The issue here is that you must use the correct schema for the id node, which I’m guessing is compiling correctly due to some past version compatibility “feature” in the Android code. Simply making the change to use android:id as shown below, made the null an issue of my past (again) and now I can move on to using the TextView any way I like.