Ruthlessly Helpful
Stephen Ritchie's offerings of ruthlessly helpful software engineering practices.
Monthly Archives: February 2012
Fake 555 Telephone Number Prefix and More
February 28, 2012
Posted by on
Unless you want your automated tests to send a text message to one of your users, you ought to use a fake phone number. In the U.S., there is the “dummy” 555 phone exchange, often used for fictional phone numbers in the movies and television.
These fake phone numbers are very helpful. For example, use these fake numbers to test the data entry validation of telephone numbers through the user interface.
example.com, example.org, example.net, and example.edu
What about automated tests that verify email address validation? Try using firstname.lastname@example.com.
In all the testing that you do, select fake Internet data:
Fake URLs: http://www.example.com/default.aspx
Fake top-level domain (TLD) names: .test, .example, .invalid
Fake second-level domain names: example.com, example.org, example.net, example.edu
Fake host names: http://www.example.com, http://www.example.org, http://www.example.net, http://www.example.edu
Source: http://en.wikipedia.org/wiki/Example.com
Source: http://en.wikipedia.org/wiki/Top-level_domain#Reserved_domains
Fake Social Security Numbers
In the U.S., a Social Security number (SSN) is a nine-digit number issued to an individual by the Social Security Administration. Since the SSN is unique for every individual, it is personally identifiable information (PII), which warrants special handling. As a best practice, you do not want PII in your test data, scripts, or code.
There are special Social Security numbers which will never be allocated:
- Numbers with all zeros in any digit group (000-##-####, ###-00-####, ###-##-0000).
- Numbers of the form 666-##-####.
- Numbers from 987-65-4320 to 987-65-4329 are reserved for use in advertisements.
For many, changing all the SSNs to use the 987-00-xxxx works great, where xxxx is the original last four digits of the SSN. If duplicate SSNs are an issue then use the 666 prefix or 000 prefix (or use sequential numbers for the center digit group) as a way to resolve duplicates.
Source: http://en.wikipedia.org/wiki/Social_security_number#Valid_SSNs
More Fake Data
There are tons of sources of fake data out on the Internet. Here is one such place to start your search:
http://www.quicktestingtips.com/tips/category/test-data/
Rules for Commenting Code
February 25, 2012
Posted by on Unreadable code with comments is inadequate code with comments you cannot trust. Code that is well written rarely needs comments. Only comments that provide additional, necessary information are useful.
Yesterday a colleague of mine told me that he lost 10 points on a university assignment because he did not comment his code. Today I saw a photo with a list of rules for commenting attributed to Tim Ottinger.
Ottinger’s three rules make a lot of sense. These rules are straightforward. In my experience, they are correct and proper. Here are Ottinger’s Comment Rules:
1. Primary Rule
Comments are for things that cannot be expressed in code.
This is common sense. But, sadly, it is not common practice. Software is written in a programming language. A reader fluent in the programming language must understand the code. The code must be readable. It must clearly express what it is that the code does.
Only add comments when some important thing must be communicated to the reader, and that thing cannot be communicated by making the code any more readable. For example, a comment with a link to the MACRS depreciation method could be important because it helps explain the source of the algorithm.
2. Redundancy Rule
Comments which restate code must be deleted.
Any restatement of the code is unlikely to maintained over time. If the comment is maintained, then it just adds to the cost. More importantly, when comments are not maintained they either end up substantially misrepresenting the code or end up being ignored. Reading comments that misrepresent code is a waste of time, at best. At worst, they cause confusion or introduce bugs. Remove any comments that restate the code.
3. Single Truth Rule
If the comment says what the code could say, then the code must change to make the comment redundant.
Writing readable code is all about making sure that the compiler properly implements what the developer intended and making sure any competent developer can quickly and effectively understand the code. The code needs to do both: completely, correctly, and consistently. For example, a comment explaining that the variable x represents the principal amount of a loan violates the single truth rule. The variable ought to be named loanPrincipal. In this way the compiler uses the same variable to represent the same single true meaning that the human reader understands.
Tim Ottinger and Jeff Langr present more pragmatic guideance on when to write (and not write) comments: http://agileinaflash.blogspot.com/2009/04/rules-for-commenting.html
Now That’s High Praise
February 19, 2012
Posted by on As a pragmatist, hearing that a fellow developer is getting a lot of value from my book is exhilarating. Dominic Zukiewicz wrote an excellent review of Pro .NET Best Practices. Here is the link to Dominic’s blog post: How to implement best practices with the .NET Framework
I’m a big fan of Steve McConnell. I’ve read most of his books and read Rapid Development cover to cover. I consider it his seminal work. It is very high praise to be compared favorably to Rapid Development.
Thank you.
Four Ways to Fake Time, Part 4
February 19, 2012
Posted by on The is the fourth and final part in the Four Ways to Fake Time series. In Part 3 you learned how to use the IClock interface to improve testability. Using the IClock interface is very effective for new application development. However, when maintaining a legacy system adding a new parameter to a class constructor might be a strict no-no.
This part looks at how a mock isolation framework can help. The goal of isolation testing is to test the code-under-test in a way that is separate from dependencies and any underlying components or subsystems. This post looks at how to fake time using the product TypeMock Isolator.
Fake Time 4: Mock Isolation Framework
The primary benefit of a mock isolation framework is that no refactoring of the code-under-test is needed. In other words, you can test legacy code as it is, without having to improve its testability before writing maintainable test code. Here is the code-under-test:
using System; using Lender.Slos.Utilities.Configuration; namespace Lender.Slos.Financial { public class ModificationWindow { private readonly IModificationWindowSettings _settings; public ModificationWindow( IModificationWindowSettings settings) { _settings = settings; } public bool Allowed() { var now = DateTime.Now; // Start date's month & day come from settings var startDate = new DateTime( now.Year, _settings.StartMonth, _settings.StartDay); // End date is 1 month after the start date var endDate = startDate.AddMonths(1); if (now >= startDate && now < endDate) { return true; } return false; } } }
With TypeMock, the magic happens in two ways. First, the test method arrangement uses the Isolate class to setup expectations. The test method sets up the DateTime.Now property so that it returns currentTime as its value. This fakes the Allowed method.
Here is the revised test code:
[TestCase(1)] [TestCase(5)] [TestCase(12)] [Isolated] // This is a TypeMock attribute public void Allowed_WhenCurrentDateIsInsideModificationWindow_ExpectTrue( int startMonth) { // Arrange var settings = new Mock<IModificationWindowSettings>(); settings .SetupGet(e => e.StartMonth) .Returns(startMonth); settings .SetupGet(e => e.StartDay) .Returns(1); var classUnderTest = new ModificationWindow(settings.Object); var currentTime = new DateTime( DateTime.Now.Year, startMonth, 13); Isolate .WhenCalled(() => DateTime.Now) .WillReturn(currentTime); // Setup getter to return the test's clock // Act var result = classUnderTest.Allowed(); // Assert Assert.AreEqual(true, result); }
Second, the test must run in an isolated environment. This is how TypeMock fakes the behavior of System.DateTime; the test is running within the TypeMock environment. Here is the TypeMock Isolator configuration window.
The Cost of Isolation
Since TypeMock Isolator is a commercial product, be prepared to make the case for purchasing Typemock. Here is some information on the business case for TypeMock: http://www.typemock.com/typemock-newsletters/2011/3/7/typemock-newsletter-march-2011.html
I find that TypeMock Isolator 6.2.3.0 is well integrated with Visual Studio 2010 SP1, ReSharper 6.1 and dotCover 1.2.
In Chapter 2 of Pro .NET Best Practices, you learn about Microsoft Research and the Pex and Moles project. Moles is a Visual Studio power tool, and you will find the latest download through the Visual Studio Gallery. As I describe, the Moles framework allows Pex to test code in isolation so that Pex is able to automatically generate tests. Therefore, you can use Moles to write unit tests that fake time.
Moles, as a way to fake time, is described in the Channel 9 post Moles – Replace any .NET method with a delegate and the blog post Did you know Microsoft makes a mocking tool?.
Just like Code Contracts, I hope and expect that Microsoft will make Moles a more significant part of .NET and Visual Studio. Today, I don’t find that Moles offers the same level of integration (for now?) with ReSharper and dotCover that TypeMock has. When I use Moles, I run my test code within their isolation environment from the command line. It works, but I really do prefer using the ReSharper test runner.
To sum up the mock isolation framework approach:
Pros:
- Works well when applied to legacy or Brownfield code
- No impact on class-users and method-callers
- A system-wide approach
- Testability is greatly improved
Cons:
- Tests must run within an isolation environment
- Commercial isolation frameworks can be cost prohibitive
I hope you found this overview of four ways to fake time to be helpful. I certainly would appreciate hearing from you about any new, different, and hopefully better ways to fake time in coded testing.
Where’s CAT.NET 2.0?
February 9, 2012
Posted by on If you go to the Microsoft Security Development Lifecycle implementation page, you read about performing static analysis with CAT.NET. If you follow one of the download links it takes you to CAT.NET v1 CTP.
About a year ago the Beta version of CAT.NET 2.0 was out from the Microsoft Security Tools team. It looked very promising. Today, I am having trouble finding the download for CAT.NET 2.0. The link on the team’s CAT.NET 2.0 – Beta blog post is broken.
There is very little information on the Information Security Tools team’s Connect site.
Does Microsoft have an update on the Security Development Lifecycle tools?
Four Ways to Fake Time, Part 3
February 7, 2012
Posted by on In Part 2 of this four part series you learned how to use a class property to change the code’s dependency on the system clock to make the code easier to test. Adding the Now property is effective, however, adding a new property to every class isn’t always the best solution.
I don’t remember exactly when I first encountered the IClock interface. I do remember having to deal with the testability challenges of the system clock about 5 years ago. I was developing a scheduling module and needed to write tests that verified the code’s correctness. I think I learned about the IClock interface when I researched the MbUnit testing framework. At some point I read about IDateTime in Ben Hall’s blog or this article in ASP Alliance. I also read about FreezeClock in Ben’s post on xUnit.net extensions. Over time I collected the ideas and background that underlie this and similar approaches.
Fake Time 3: Inject The IClock Interface
I usually create a straightforward IClock interface within some utility or common assembly of the system. It becomes a low-level primitive of the system. In this post, I simplify the IClock interface just to keep the focus on the primary concept. Below I provide links to more detailed and elaborate designs. Without further ado, here is the basic IClock interface:
using System; namespace Lender.Slos.Utilities.Clock { public interface IClock { DateTime Now { get; } } }
By using the IClock interface, the code in our example class is modified so that it has a dependency on the system clock through a new constructor parameter. Here is the rewritten code-under-test:
using System; using Lender.Slos.Utilities.Clock; using Lender.Slos.Utilities.Configuration; namespace Lender.Slos.Financial { public class ModificationWindow { private readonly IClock _clock; private readonly IModificationWindowSettings _settings; public ModificationWindow( IClock clock, IModificationWindowSettings settings) { _clock = clock; _settings = settings; } public bool Allowed() { var now = _clock.Now; // Start date's month & day come from settings var startDate = new DateTime( now.Year, _settings.StartMonth, _settings.StartDay); // End date is 1 month after the start date var endDate = startDate.AddMonths(1); if (now >= startDate && now < endDate) { return true; } return false; } } }
Under non-test circumstances, the SystemClock class, which implements the IClock interface, is passed through the constructor. A very simple SystemClock class looks like this:
using System; namespace Lender.Slos.Utilities.Clock { public class SystemClock : IClock { public DateTime Now { get { return DateTime.Now; } } } }
For those of you who are using an IoC container, it should be clear how the appropriate implementation is injected into the constructor when this class is instantiated. I recommend you use constructor DI when using the IClock interface approach. For those following a Factory pattern, the factory class ought to supply a SystemClock instance when the factory method is called. If you’re not loosely coupling your dependencies (you ought to be) then you need to add another constructor that instantiates a new SystemClock, kind of like this:
public ModificationWindow(IModificationWindowSettings settings) : this(new SystemClock(), settings) { }
In this post, we are most concerned about improving the testability of the code-under-test. The revised test method sets up the IClock.Now property so as to return currentTime as its value. This, in effect, fakes the Allowed method, and establishes a known value for the system clock. Here is the revised test code:
[TestCase(1)] [TestCase(5)] [TestCase(12)] public void Allowed_WhenCurrentDateIsInsideModificationWindow_ExpectTrue( int startMonth) { // Arrange var settings = new Mock<IModificationWindowSettings>(); settings .SetupGet(e => e.StartMonth) .Returns(startMonth); settings .SetupGet(e => e.StartDay) .Returns(1); var currentTime = new DateTime( DateTime.Now.Year, startMonth, 13); var clock = new Mock<IClock>(); clock .SetupGet(e => e.Now) .Returns(currentTime); // Setup getter to return the test's clock var classUnderTest = new ModificationWindow( clock.Object, settings.Object); // Act var result = classUnderTest.Allowed(); // Assert Assert.AreEqual(true, result); }
If you’re looking for more depth and detail, take a look at this very good post on the IClock interface by Al Gonzalez: http://algonzalez.tumblr.com/post/679028234/iclock-a-test-friendly-alternative-to-datetime
The Gallio/MbUnit testing framework has its own IClock interface. I don’t like production deployments containing testing framework assemblies; however, the Gallio approach offers a few ideas to enhance the IClock interface.
Pros:
- Works well with an IoC Container/Dependency Injection approach
- Can work with .NET Framework 2.0 and later
- No impact on class-users and method-callers
- A system-wide approach
- Testability is greatly improved
Cons:
- System-wide change, some risk
- Can be disruptive when applied to legacy or Brownfield applications
I often use this approach when working in Greenfield application development or when major refactoring is warranted.
In the next part of this Fake Time series we’ll look at a mock isolation framework approach.
.NET Developer’s Journal Book Review
February 3, 2012
Posted by on Tad Anderson wrote an excellent review of Pro .NET Best Practices in the .NET Developer’s Journal.
Here’s a link to Tad’s original blog post: Real World Software Architecture: Pro .NET Best Practices Book Review