Today is Friday, 10th August 2018

Archive for the ‘Test Driven Development’ Category


Unit Testing a Password Utility

In this post, we are going to develop a password utility. The utility has to support password validation.

Here are the password security rules for the application:

  • at least 8 characters, max of 12
  • at least one uppercase
  • at least one lowercase
  • at least one number
  • at least one symbol @#$%=:?

In regular TDD fashion, we’ll first set out to develop unit tests that will test the functionality of the application. Based on the security rules above, we will develop unit tests for the following conditions:

  • Test for null string
  • Test for empty string
  • Test for max of 12 characters
  • Test for at least one uppercase
  • Test for at least one lowercase
  • Test for at lest one number
  • Test for at least one symbol

There a number of ways to perform the validation on the password. However, the best solution for this is a regular expression. Agreed that it takes a bit of time to develop the regular expression, but the test cases will help drive us to the correct solution.

So let’s get started with the unit tests. Based on the information above, we have the following unit tests.

package com.luv2code.password.util;
import org.junit.Test;
import static org.junit.Assert.*;
/**
*
* @author Chad Darby, darby@luv2code.com
*/
public class PasswordUtilsTest {
@Test
public void validatePassword_Null() {
// setup
String password = null;
// execute
boolean actual = PasswordUtils.validatePassword(password);
// assert
assertFalse(actual);
}
@Test
public void validatePassword_EmptyString() {
// setup
String password = "";
// execute
boolean actual = PasswordUtils.validatePassword(password);
// assert
assertFalse(actual);
}
@Test
public void validatePassword_Missing_OneNumber() {
// setup
String password = "Abcdefg#";
// execute
boolean actual = PasswordUtils.validatePassword(password);
// assert
assertFalse(actual);
}
@Test
public void validatePassword_Missing_OneUpperCaseLetter() {
// setup
String password = "abcdefg5#";
// execute
boolean actual = PasswordUtils.validatePassword(password);
// assert
assertFalse(actual);
}
@Test
public void validatePassword_Missing_OneLowerCaseLetter() {
// setup
String password = "ABCDEFG5#";
// execute
boolean actual = PasswordUtils.validatePassword(password);
// assert
assertFalse(actual);
}
@Test
public void validatePassword_Missing_OneSymbol() {
// setup
String password = "Abcdefg5";
// execute
boolean actual = PasswordUtils.validatePassword(password);
// assert
assertFalse(actual);
}
@Test
public void validatePassword_AllRulesMet() {
// setup
String password = "Abcdefg5#";
// execute
boolean actual = PasswordUtils.validatePassword(password);
// assert
assertTrue(actual);
}
@Test
public void validatePassword_LengthTooLong() {
// setup
String password = "Abcdefg5#abcdefgabcd";
// execute
boolean actual = PasswordUtils.validatePassword(password);
// assert
assertFalse(actual);
}
}

Now, we can move forward to the implementation. Essentially, we need to develop a method with the following signature:

/**
* Returns true if password matches the validation rules
*
* @param password
* @return
*/
public static boolean validatePassword(String password) {
return true;
}

Failing Tests

In true TDD fashion, this implementation will cause the majority of our tests to fail. It will fail for all invalid passwords. Our first run of the test cases will generate failures. Now, we can update the implementation to return the correct results. As I mentioned earlier, we’ll make use of a regular expression to validate the password.

package com.luv2code.password.util;
/**
*
* @author Chad Darby, darby@luv2code.com
*/
public class PasswordUtils {
private static final String VALID_PASSWORD_REGEX = "((?=.*\\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[@#$%=:\\?]).{8,12})";
/**
* Returns true if password matches the validation rules
*
* @param password
* @return
*/
public static boolean validatePassword(String password) {
return (password != null && password.matches(VALID_PASSWORD_REGEX));
}
}

Passing Tests

As you can see in the validatePassword method, the conditional checks to make sure the password is not null. This supports one of the first test cases. Now, to meet the validation rules, we make use of the regular expression:

((?=.*\\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[@#$%=:\\?]).{8,12})

Now, I know that looks like a really gnarly piece of gibberish, but let’s break it down one section at a time.

ExpressionDescription
(?=.*\\d)at least one digit
(?=.*[a-z])at least one lowercase
(?=.*[A-Z])at least one uppercase
(?=.*[@#$%=:\\?])at least one symbol @#$%=:?
{8,12}minimum of 8 characters, max of 12

That’s pretty much it. The regular expression is the bulk of development for this validation routine. It is nice that we were able to minimize the implementation to just a couple of lines of code. The unit tests provide coverage for the happy path, error conditions (null strings) and the edge cases.

The source code is available here.

Enjoy!



Unit Testing Java Email Code with Fake SMTP Server

What is your testing strategy for sending emails from your Java application? Do you hard-code your developer email in the application? I’ve been there and done that (not too proud though). Ideally, you would like to use the actual email addresses in your testing process. However, you do not want to send the email to the actual recipient. You would also like to view the message and validate/assert the message is correct.

One possible solution is to install a local email server and run your tests against the server. However, this requires that you create accounts for all of your test data or customer data.

I found a really great open-source solution to this problem, Wiser. Wiser is a fake SMTP server written in Java. You can use it for unit testing your application that sends email. It accepts all email messages and stores them in memory. Then you can call an API method to retrieve the messages. All of this can run in the same VM as your unit test…really slick!

It is really easy to get started using Wiser:

Step 1:  Start Wiser in your Java code

Wiser wiser = new Wiser();
wiser.setPort(2500); // Default is 25
wiser.start();

Step 2:  Call your Java code to send email to the Wiser server

// your JavaMail code

Step 3: Retrieve messages from Wiser

for (WiserMessage message : wiser.getMessages()) {
String envelopeSender = message.getEnvelopeSender();
String envelopeReceiver = message.getEnvelopeReceiver();
MimeMessage mess = message.getMimeMessage();
// now do assert the message headers and contents
}

That’s it.  Take a look at Wiser’s website to get the JAR files. Enjoy!



How to add Unit Testing to a Legacy Project

Source: InfoQ

It is always a herculean task to write automated regression tests for a legacy application. The questions vary from where to start, how much to automate and deciding on the best strategy for automation.

Responding to a thread started by Mark Levison on the Agile software testing group, Hubert Matthews suggested that the approach that he recommends is a risk based approach.

You can never test everything so you have to choose where you want to spend your time and money. Testing for me is primarily about information and risk and not about blanket coverage or completeness.

Read Complete post…