Unit Tests, wonderful Unit tests

As I've mentioned before, I quite like unit tests. At the hands of Adam I've learnt to love and respect them. So when I had to write a simple function to ensure a password:

• Is at least eight characters
• Contains an upper-case character
• Contains a lower-case character
• Contains a digit
• Contains a special character
  

I thought this would be a great reason to add some new unit tests in. Plus I'll be damned if I'm going to do all the typing on a phone to test and register all the various cases I can think of. As it happens this turned out to be a great idea because there was at least one case I'd missed.

Kids, unit tests work!

I thought I'd turn this into a challenge, how would you write the desired function? I'll provide the unit tests and you can impress me with your regex or your clever functions! Feel free to use any language you so desire. Winner gets the glory!

    @SmallTest
    public void testBlank(){
        String password = "";
        assertFalse(Utils.isPasswordValid(password));
    }

    @SmallTest
    public void testLower(){
        String password = "a";
        assertFalse(Utils.isPasswordValid(password));
    }

    @SmallTest
    public void testUpper(){
        String password = "A";
        assertFalse(Utils.isPasswordValid(password));
    }

    @SmallTest
    public void testNumber(){
        String password = "123";
        assertFalse(Utils.isPasswordValid(password));
    }

    @SmallTest
    public void testPadded(){
        String password = "     ";
        assertFalse(Utils.isPasswordValid(password));
    }

    @SmallTest
    public void testWhite(){
        String password = "\t\t";
        assertFalse(Utils.isPasswordValid(password));
    }

    @SmallTest
    public void testGood(){
        String password = "ab12CD*!";
        assertTrue(Utils.isPasswordValid(password));
    }

    @SmallTest
    public void testNoUpper(){
        String password = "ab12cd*!";
        assertFalse(Utils.isPasswordValid(password));
    }

    @SmallTest
    public void testNoLower(){
        String password = "AB12CD*!";
        assertFalse(Utils.isPasswordValid(password));
    }

    @SmallTest
    public void testNoNumber(){
        String password = "abcdCD*!";
        assertFalse(Utils.isPasswordValid(password));
    }

    @SmallTest
    public void testNoSymbol(){
        String password = "abcdCD12";
        assertFalse(Utils.isPasswordValid(password));
    }

    @SmallTest
    public void testGoodLong(){
        String password = "abcdCD12*&asdbbs167672HGSAHGAS!&^";
        assertTrue(Utils.isPasswordValid(password));
    }

    @SmallTest
    public void testGoodOne(){
        String password = "aaaaaA1\"";
        assertTrue(Utils.isPasswordValid(password));
    }

Android Studio Build Types

Android Studio, somewhat predictably, allows two deployment modes debug and release. Configuring this in gradle allows you to configure certain options like if we should use proguard or not and what signing config to use. However this can be taken further to allow customization of certain java files based on release or debug build.

I’m not talking here about flavours, which is something slightly different. What I want to do is use one java class for debug and a different one for a release build. This allows me to suppress some debugging functions on a release build.

1. Create a Simple Project

First I create a new project and quickly setup a simple MainActivity with a button to launch a SecondActivity. I’m going to keep these activities very simple just to prove the concept. Don’t create the SecondActivity yet, we’ll do it in the next step.

2. Create Build Types

First update your app/build.gradle file to reflect the following, note the buildTypes:

apply plugin: 'com.android.application'

android {
    compileSdkVersion 21
    buildToolsVersion "21.1.2"

    defaultConfig {
        applicationId "com.example.android.myapplication"
        minSdkVersion 10
        targetSdkVersion 21
        versionCode 1
        versionName "1.0"
    }

    signingConfigs {
        debug {
            storeFile file("--path-to-debug-keystore--")
        }
        release {
            storeFile file("--path-to-release-keystore--")
            storePassword "--password--"
            keyAlias "--alias--"
            keyPassword "--password--"
        }
    }

    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
            signingConfig signingConfigs.release
        }
        debug {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
            signingConfig signingConfigs.debug
        }
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:appcompat-v7:21.0.3'
}

Note I’ve included a release keystore here with password and alias password. This is obviously not recommended for a real app. You would ideally release using the “Generate Signed APK…” However I’ve done it in this example as it allows me to quickly release using the build button.

3. Create folder structure

Create release and debug folders inside src. Inside both create a java folder, one (normally debug) will go blue and allow you to create a package. Create a new package matching your default package. In the other (normally release) you’ll have to just create folders instead of a package. Now create a SecondActivity.java in both. As the image below shows, you'll never get both release and debug to be correctly marked as a package. However when you switch using the build variants tab, you'll see the currently selected one change.

4. Test

Now you’re setup to configure your second activity as you wish, in my example I had each update a textview to say debug or release. Open the Build Variants tab in Android Studio and switch between build variants. This allows you to toggle the modes and release as such.