Androidsx is now Perops. Visit us at perops.com

Androidsx Androidsx | android and wearable developers

 

Subscribe for market insights and new posts

 

How to write untestable code

January 14, 2010 at 11:08 am | blog, software quality | 2 comments

 

Say that we write code for a machine that it so powerful that rumors say it could generate a black hole. We need to be serious about security: we cannot let those evil international terrorists find out our black-hole-making secrets and blow half the Milky Way Galaxy.

If they managed to access our source code, they could extend it and adapt it to their cruel use case, which would represent a huge threat for the humankind. In order to reduce risks, we should write code that is difficult to understand, to maintain and of course, to test. Here’s how:

  • Depend on concrete classes – Tie things down to concrete classes – avoid interfaces wherever possible: they let people substitute the concrete classes you’re using for their own classes which would implement the same contract in the interface. By depending on concrete implementation, we make sure that they’ll have a hard time testing whether their evil plans will release enough energy to toast their breakfast bread.
  • Make your own dependencies – Instantiate objects using new in the middle of methods, don’t pass the object in. Anyone that wants to test that code is forced to use that concrete object you new’ed up: they can’t inject a dummy, fake, or other mock in to simplify the behavior or make assertions about what you do to it.
  • Conditional slalom – Feel good when writing lengthy if branches and switch statements. These increase the number of possible execution paths that tests will need to cover when exercising the code under test. The higher the cyclomatic complexity, the harder it is to test and understand! Why use polymorphism instead of conditionals? Don’t make it so easy! Make the branching both deep and wide: if you’re not consistently going at least 5 conditionals deep, the patient terrorists might even find out what the code intends to do under all possible combinations.

    It is also known as the Arrow Antipattern:

    if a
        if b
            if c
                foo();
            else
                bar();
            endif
        endif
    endif
    

    Refactoring into something more suitable is usually possible:

    if a && b
        if c
            foo();
        else
            bar();
        endif
    endif
    
  • Use global flags – Why call a method explicitly? Set a flag in one part of your code, in order to cause an effect in a totally different part of your application. The testers will go crazy trying to figure out why all of a sudden a conditional that was evaluating true one minute is all of a sudden evaluating to false. Not to mention the mess that using that system becomes: if we manage to keep the wikis safe from their hands, they’ll have a very hard time figuring out what system properties to set in order to get the deadly weapon working.
  • Loop-switch sequence – By means of which a clear set of steps is implemented as a byzantine switch-within-a-loop. Fulfilling our mission to obfuscate the code , is much more difficult to decipher the intent and actual function of the code than the more straightforward refactored solution.

    This is a terrorist-safe code snippet:

    // parse a key, a value, then three parameters
    String key = null;
    String value = null;
    final List params = new LinkedList();
    
    for (int i = 0; i < 5; i++) {
      switch (i) {
        case 0: key = stream.parse(); break;
        case 1: value = stream.parse(); break;
        default: params.add(stream.parse()); break;
      }
    }
    

    While this is too easy to understand:

    // parse a key and value
    final String key = stream.parse();
    final String value = stream.parse();
    
    // parse 3 parameters
    final List params = new LinkedList();
    for (int i = 0; i < 3; i++) {
      params.add(stream.parse());
    }
    

References: This post on the Google Testing Blog, the Arrow AntiPattern in Cunningham & Cunningham webpage.

Related posts

Tags:

<< Back to Blog Discuss this post

 

Checkout our new pet project:

Subscribe to our newsletter

 

2 Comments to “How to write untestable code”

  1. Luis Solano says:

    Completely agree! In my college we only learn anti-terrorist programming.

  2. Dean Woelfel says:

    I have not long ago started an internet site, as well as the facts you offer you on that web site has helped me a tremendous amount. Thanx for all of your moment & function.

Categories:

Recent posts:

Search:

Subscribe