Browse by Category

Has the Time for a Mandate Finally Arrived?

Breaking ThroughPeople get comfortable doing things a certain way and, even when it makes sense to change, they won’t unless they are compelled to do so. They become emotionally attached to their routine and don’t want to leave their comfort zone. Fear of the unknown, negative assumptions, not-a-good-time thinking and past failures are all reasons why change may not happen in the end. This truism holds within the Federal Government as well. In the public sector there’s the additional reason of doing things the same old way because—so far—no one has gotten in trouble. Not yet, anyway.

My observation from thirty-three years of experience working on the inside is that real change cannot be effected without a mandate. Usually these mandates come from Congress: Competition in Contracting Act (1984), the Defense Acquisition Workforce Improvement Act (1994), the Sarbanes-Oxley Act (2002)—and have you seen the FY 2013 National Defense Authorization Act changes to acquisition? But it is possible for DOD and Federal Agencies to make policy changes on their own.

In the early days of the Internet the “If you build it, they will come” perspective of the advocates was tinged with a healthy dose of, “… if it’s really worth doing at all” from the skeptics. Websites like DOD EMALL and GSA Advantage soldiered on and have collectively captured over $1.5 billion in annual Government spending—all on small stuff, a few hundred bucks at a time. Now is the time for the Federal Government to recognize the value of what it has and leverage that value to get over the bar.

A policy mandate that requires Government Purchase Card holders to source their items in specific categories from these Government-owned, built-for-Government’s-purpose assets will give the Government the ability to:

  • Capture the data about what Government Purchase Card holders are really buying.
  • Leverage that total buying power through Strategic Sourcing (which is based on knowing what you are going to be buying LOTS of).
  • Monitor for compliance to laws and regulations as well as appropriateness of items purchased.

While the perfect time to mandate use of US Government-sanctioned eCommerce platforms would have been when GPCs were first being issued, they emerged at about the same time, so it is not too late for a course correction.

By not issuing this mandate, the Federal Government is sending the message that GPC card holders have freedoms that the policy makers really don’t want them to have. In the Department of Defense, Purchase Card On-Line (PCOLS) has a data collection tool that has the stated purpose of monitoring for fraud, but the “sophisticated intelligent/learning software” (see PCOLS White Paper) in the Data Mining module will only be as good as the data within it. If GPC holders were required to seek what they needed on DOD EMALL or GSA Advantage first, the acquisition of supplies and the collection of this detail-rich data would be merged into one process, which would be a change for the better.

Next time we’ll talk about the question that I know is on your mind, “But what if I needed something that is not on DOD EMALL or GSA Advantage!?”

Government Acquisition Players Benefit from eCommerce

Shopping CartPlayers in the world of government acquisition abound: acquisition policy makers, who determine how purchases will be made; customers who have the need for products; contracting officers, who write the contracts; vendors, who supply the goods and services; logisticians, who store the items in a government warehouse; and the taxpayers, who ultimately pay the bill for the products. All of these players benefit from eCommerce in different ways. Let’s look closer at the benefits for each group.

Policy Makers

Policy makers benefit by developing an enterprise wide acquisition strategy for simplified acquisitions, which simplifies the process, saves money, and increases small business goals. eCommerce also increases business intelligence because purchases are consolidated in a single place.

Customers

Customers, who are looking for small repetitive buys, especially when they are for commercial type items, benefit from the self-service aspect of eCommerce. They don’t have to leave their desk to make purchases; they can compare prices of multiple vendors and the product arrives at their desk, usually within 3-5 days. This type of action is far superior to the traditional 30-90 day acquisition cycle for small purchases.

Contracting Officers

The contracting officers benefit because eCommerce reduces duplication of procurement costs and develops strategic partnerships with vendors. Once they do the contracting work and select a vendor or series of vendors for a commodity area, they can move on to more complicated acquisitions. Making commercial type contracts available on government eCommerce sites like DOD EMALL and GSA Advantage and allowing self-service purchase orders, greatly reduces day-to-day contracting workload. Additionally, eCommerce provides a level of automation for the contacting community.

Vendors

Vendors also see a number of benefits. They can gain access to worldwide markets with minimal marketing costs. Small business can compete directly with large business and they can easily track purchases and use this to better understand the needs of their customers.

Government Logisticians

Right now, government budgets are really tight and government logisticians are always looking at ways to save money by reducing inventory. Putting commercial type items on long-term contracts and making them available on government eCommerce sites can greatly reduce the stock kept in government warehouses. Global vendors have the ability to provide stock worldwide in a very short time frame or can ship directly to government consolidation points for overseas shipment.

Taxpayers

Lastly, the taxpayer benefits with lower government acquisition costs. Studies within the government by GSA Advantage, Seaport-E, and DOD EMALL have shown that eCommerce purchases can save 7-15% in purchases costs and up to 25-30% in purchasing process costs.

No matter whose perspective you use, eCommerce is a good idea for government acquisition. Unfortunately it is a much underutilized tool in the government acquisition tool box. Why do you think the federal government has been slow in utilizing this technology that has been around for almost 20 years?

Five Little Stars: Product Reviews for Government eCommerce

Shopping Cart on LaptopCustomer product reviews are a staple of nearly every type of eCommerce site except for one: government. While governments at the federal, state and local levels have adopted eCommerce for either payment purposes or procurement support, a taboo prevails: allowing customers of government-operated eCommerce sites the opportunity to say what they think about the products offered there.

As a private consumer, I cannot imagine making decisions about purchasing something that I couldn’t physically inspect without further information of some kind. What those who already own and use the product think is invaluable. Consumer product reviews are the answer to the questions about features not covered in the manufacturer’s marketing materials. They provide you with a warning about potential pitfalls or difficulties encountered when using a product. And their information can be vital in helping you determine which product to choose when most other factors are equal. Need an example? Let’s say that you need to buy 100 hammers to restock your maintenance shop? You find three hammer offerings, all the same price, weight and purpose and now you have to choose. What if one of the offerings had a product review that enthused about how the comfortable cushioned grip was ideal for big jobs; would that inform your decision? Of course it would!

The public sector has seen a high rate of adoption for eCommerce from access and sharing of records, and payment of taxes and fees, to acquisition of supplies and services needed in the conduct of government business. Since governments perform the acquisition of these supplies with funds collected from taxpayers, there is a fiduciary responsibility that both you and I should want taken seriously.

One area, particularly in the federal sector, that is highly regulated is contractor past performance (see Federal Acquisition Regulation Part 42.15). Since other acquisition professionals may use data regarding contractor performance in determining a contractor’s ability to perform on a new contract, the integrity of how data is collected and conveyed must be protected in order to ensure a level playing field. But is contractor performance and information about the product a contractor sells really the same thing? I don’t believe it is. Furthermore, if the information presented on a government website is clearly labeled, the need for transparency has been met.

Picture five little stars in a row with a label above saying “Customer-Provided Product Review” and a text box that appears when you hover over it that says, “This rating represents the average of all website users who have rated this product and does not reflect the opinion of the US Government regarding either the product or the contractor providing the product. This rating is supplied for information only.” There are few people ordering supplies within the federal government today that are unfamiliar with web-based ordering and the concept of customer product reviews. Customer reviews are a standard, better yet, best practice for eCommerce. The disclaimer covers any liability the Government’s might incur by stating that the opinion is unofficial, and the customer wins by being given valuable information that they could only get by picking up the object and using it for themselves.

It is not unusual to see feedback from users of government websites complaining that it’s just not user-friendly. However, when pressed for details, these users may find it difficult to articulate a specific problem. Government sites would be wise to adopt the commercial standard of providing starred reviews, which would go a long way to improve the perception of user friendliness by increasing the consumer’s understanding of the items available. To take this a step further, government eCommerce websites could benefit from incorporating the look and feel of their commercial counterparts to help their weary users feel more comfortable by operating in an arena with which they are familiar. So, what ideas would you offer to government eCommerce sites? Do you think consumer product reviews would be beneficial or would they be a problem? Sound off below.

EasyMock Fundamentals Series — Part 3

Tech 3Welcome to the third and final installment in my EasyMock Fundamentals series, where I take you through the ins and outs of the open source Java library. EasyMock can be used in conjunction with a unit testing framework, such as JUnit or TestNG, to facilitate better unit testing without all the 2nd degree dependency issues. EasyMock provides the means (through the use of mock objects) to specify the response that will be returned when the code being tested makes calls to external methods. This will allow the result of the unit test to be isolated from variables outside of the scope of the unit test code.

Argument Matching

Argument matching is related to setting up expectations and is one of those subtleties of EasyMock that you might miss and certainly not understand until you really start writing tests.

The following shows setting up an expectation without any argument matchers:

EasyMock.expect(mockEmailer.sendEmail("foodaddy")).andReturn(true);

In this scenario, you’re telling EasyMock to return true when sendEmail() is called with "foodaddy" as the parameter. Simple enough, but what if you wanted tell EasyMock to return true for all parameter values, or only certain parameter values, or only on Tuesdays, etc? This is where argument matchers come to play.

The following demonstrates an argument matcher that matches all String values:

EasyMock.expect(mockEmailer.sendEmail(EasyMock.isA(String.class))).andReturn(true);

What about all String values except "foodaddy"?

EasyMock.expect(mockEmailer.sendEmail(EasyMock.not(EasyMock.eq("foodaddy")))).andReturn(true);

EasyMock supports a wide selection of argument matchers that can be used to create any type of matcher. Here are some of the matcher methods:  anyInt(), anyObject(), contains(), eq(), geq(), gt(), isA(), leq(), lt(), same(), startsWith().

Argument matchers can be combined using the following methods:  and(), or(), not()

Consult the API for a complete listing, but as an example:

// true for "foodaddy" or "foo.*daddy"
EasyMock.expect(mockEmailer.sendEmail(
          EasyMock.or(EasyMock.eq("foodaddy"),
                      EasyMock.and(EasyMock.startsWith("foo"),
                                   EasyMock.endsWith("daddy")))
                      )).andReturn(true);

EasyMock even has support for creating custom argument matchers. Consult the API for more info. For more info on argument matchers, see this blog post.

Argument Matching — Part 2

EasyMock has this annoying feature/limitation that prevents mixing non-argument matchers (raw values) with argument matchers when setting up expectations. I often encounter this when trying to setup expectations for a method that takes multiple parameters where some are simple primitives and others are complex types. This can be annoying because often times you want to be able to setup your expectations in this way. Given the following:

public interface Emailer {
  boolean sendEmail(String emailAddress, String message);
}
public class Foo {
  private Emailer emailer;
  public Foo(Emailer emailer) {
    this.emailer = emailer;
  }
  public void doSomethingCool(boolean useDefault, String emailAddress) {
    String message = null;
    if (useDefault) {
      message = "default message";
    }
    else {
      message = "something else";
    }
    emailer.sendEmail(emailAddress, message);
  }
}

So now you want to test this code so you start as follows:

public class TestFoo {
  @Test
  public void test_doSomethingCool()
  {
    final String emailAdrs = "foo@foodaddy.com";
    Emailer mockEmailer = EasyMock.createMock(Emailer.class);
    // return true when emails are sent to foo@foodaddy.com regardless of the message being sent
    EasyMock.expect(mockEmailer.sendEmail(emailAdrs, EasyMock.isA(String.class))).andReturn(true);
    EasyMock.replay(mockEmailer);
    Foo myFoo = new Foo(mockEmailer);
    myFoo.doSomethingCool(true, emailAdrs);

    EasyMock.verify(mockEmailer);
  }
}

As the comment above states, you don’t care what message is being sent to “foo@foodaddy.com“. You want all emails sent to "foo@foodaddy.com" to return true. Seems valid enough, but when you run your test, you’ll get an error message similar to this:

java.lang.IllegalStateException: 2 matchers expected, 1 recorded. This exception usually occurs when matchers are mixed with raw values when recording a method: You need to use no matcher at all or a matcher for every single parameter:

Huh? The key is “…_matchers are mixes with raw values_…”. Unfortunately, you can’t do what you were hoping to do. EasyMock requires that you use ALL raw values or ALL argument matchers in a given expectation. So the following shows how you accomplish this:

public class TestFoo {
  @Test
  public void test_doSomethingCool()
  {
    final String emailAdrs = "foo@foodaddy.com";
    Emailer mockEmailer = EasyMock.createMock(Emailer.class);
    EasyMock.expect(mockEmailer.sendEmail(EasyMock.eq(emailAdrs), EasyMock.isA(String.class))).andReturn(true);
    EasyMock.replay(mockEmailer);
    Foo myFoo = new Foo(mockEmailer);
    myFoo.doSomethingCool(true, emailAdrs);
    EasyMock.verify(mockEmailer);
  }
}

The eq() argument matcher is what’s needed here and is especially handy at matching primitive values. The eq() argument matcher can certainly be used to match more complex types, but with primitives, you don’t have to worry about the implementations of equals() and hashCode() as discussed next.

Captures

These are cool, but the documentation and examples I’ve found are not. I like examples so hopefully the following will demonstrate Capture‘s coolness. Given the following:

public class Recipient {
  private String name;
  private String email;
  public Recipient(String name, String email) {
    this.name = name;
    this.email = email;
  }
  // getters for above attrs
}
public interface Emailer {
  boolean sendEmail(Recipient r, String message);
}
public class Foo {
  private Emailer emailer;
  public Foo(Emailer emailer) {
    this.emailer = emailer;
  }
  public void doSomethingCool(boolean useDefault) {
    Recipient r = null;
    if (useDefault) {
      r = new Recipient("foodaddy", "foo@part.net");
    }
    else {
      r = new Recipient("noreply", "noone@part.net");
    }
    emailer.sendEmail(r, "some message");
  }
}

So the question is, how would you test the doSomethingCool() code and ensure that the if/else conditional evaluation is being done correctly? Granted, this is a simple example, but the question is still valid. There are 2 possibilities.

  • 1) Implement equals() and hashCode() on the Recipient object so that their implementation, specifically equals(), could be used in your unit test as follows.
public class TestFoo {
  @Test
  public void test_doSomethingCool()
  {
    {
      Recipient recOne = new Recipient("foodaddy", "foo@part.net");
      Emailer mockEmailer = EasyMock.createMock(Emailer.class);
      // this next line is the key - we're relying on the fact that recOne.equals(recipient) == true - where recipient is the one created in doSomethingCool()
      EasyMock.expect(mockEmailer.sendEmail(recOne, ...)).andReturn(true);
      EasyMock.replay(mockEmailer);
      Foo myFoo = new Foo(mockEmailer);
      myFoo.doSomethingCool(true);
      EasyMock.verify(mockEmailer);
    }
    {
      Recipient recTwo = new Recipient("noreply", "noone@part.net");
      Emailer mockEmailer = EasyMock.createMock(Emailer.class);
      // same comment as before
      EasyMock.expect(mockEmailer.sendEmail(recTwo...)).andReturn(true);
      EasyMock.replay(mockEmailer);
      Foo myFoo = new Foo(mockEmailer);
      myFoo.doSomethingCool(false);
      EasyMock.verify(mockEmailer);
    }
  }
}

As was noted in the code, the key is that we’re relying on the implementation of Recipient.equals().

 

On the test code line:

mockEmailer.sendEmail(recOne, ...);

two things are occurring:

  1. You are setting up an expectation that the sendEmail() method will be called
  2. The Recipient that is passed to sendEmail() will be equal to the one provided.

Even though the same Recipient object instance (recOne != recipient) is not used in the expectation, the two different instances are considered equal:

recOne.equals(recipient) == true

By not including an argument matcher explicitly, EasyMock is using object equality (equals()) to match. This is the same as using the eq() argument matcher.

While this approach is certainly valid, it’s less than ideal because it requires that equals() be implemented. Furthermore, the implementation of equals() has to be known and understood how to be taken advantage of (i.e. you have to know that name and email are used in equals() rather than something like an id attribute). Additionally, you’re not able to actually test/assert against the attribute values of the created Recipient. That’s essentially what’s being done by taking advantage of the implementation of equals(), but it’s less explicit and obvious to the poor maintenance developer.

  • 2) The second (and better) approach is to use an EasyMock Capture as follows to retrieve, err capture, the actual instance of the Recipient object created by the doSomethingCool() method.
public class TestFoo {
  @Test
  public void test_doSomethingCool()
  {
    {
      Emailer mockEmailer = EasyMock.createMock(Emailer.class);
      Capture rCap = new Capture();
      EasyMock.expect(mockEmailer.sendEmail(EasyMock.capture(rCap), ...)).andReturn(true);
      EasyMock.replay(mockEmailer);
      Foo myFoo = new Foo(mockEmailer);
      myFoo.doSomethingCool(true);
      EasyMock.verify(mockEmailer);
      Recipient recipient = rCap.getValue();  // actual Recipient instance returned here
      Assert.assertEquals(recipient.getName(), "foodaddy");
      Assert.assertEquals(recipient.getEmail(), "foo@part.net");
    }
    {
      Emailer mockEmailer = EasyMock.createMock(Emailer.class);
      Capture rCap = new Capture();
      EasyMock.expect(mockEmailer.sendEmail(EasyMock.capture(rCap), ...)).andReturn(true);
      EasyMock.replay(mockEmailer);
      Foo myFoo = new Foo(mockEmailer);
      myFoo.doSomethingCool(false);
      EasyMock.verify(mockEmailer);
      Recipient recipient = rCap.getValue();  // actual Recipient instance returned here
      Assert.assertEquals(recipient.getName(), "noreply");
      Assert.assertEquals(recipient.getEmail(), "noone@part.net");
    }
  }
}

Using a Capture has none of the requirements/drawback/quirks as the first approach and is certainly no harder to use.

Links

 


This is the last in my three-part EasyMock Fundamentals series. Please leave questions and comments in the comments section below. If you missed them, be sure to take a look at EasyMock Fundamentals — Part 1 and EasyMock Fundamentals — Part 2.

EasyMock Fundamentals Series — Part 2

Tech 1-01Welcome to the second installment of my EasyMock Fundamentals series where I take you through the ins and outs of the open source Java library, EasyMock. EasyMock can be used in conjunction with a unit testing framework, such as JUnit or TestNG, to facilitate better unit testing without all the 2nd degree dependency issues. EasyMock provides the means (through the use of mock objects) to specify the response that will be returned when the code being tested makes calls to external methods. This will allow the result of the unit test to be isolated from variables outside of the scope of the unit test code.

Mocking Objects

Basic steps for EasyMock use

1. Import EasyMock

  • import static org.easymock.EasyMock.*;  // non-static imports may also be used

2. Create mock object

  • private ClassOrInterface mock;
  • mock = createMock(ClassOrInterface.class);  // throws AssertionErrors for all unexpected method calls
  • mock = createNiceMock(ClassOrInterface.class);  // allows all method calls and returns appropriate empty values (0, null or false)

3. Specify expectations for mock (in other words, “I’m going to tell you what you should expect to do”)

  • mock.doThis();
  • mock.doThat();
  • specify that the last method could be called x times
    • expectLastCall().once();  // default one call
    • expectLastCall().times(3);  // exact calls
    • expectLastCall().times(2, 5);  // min, max calls
    • expectLastCall().atLeastOnce();  // one or more times
    • expectLastCall().anyTimes();  // 0 or more times
    • specify method response or return value
      • expect(mock.doThis()).andReturn(returnValue, i.e. “true”);

4. Make mock available for use (in other words, “I’m done telling you what you should expect to do, now get ready to do it.”)

  • replay(mock)

5. Run unit test that will call doThis() and doThat()

  • verify proper response
    • assertTrue(doThis());

6. Verify that expected behavior was called (did everything get called the expected number of times?)

7. Verify(mock)

Tips

Prefer Nice Mocks

There are basically 3 different ways to have EasyMock create a mock object for you.

  1. createMock(Foo.class)
  2. createNiceMock(Foo.class)
  3. createStrictMock(Foo.class)

Each way gives you a mock object with slightly different behaviors/restrictions. Consult the EasyMock API for specifics, but unless you have valid reason to not, the preferred method is createNiceMock(). Nice mocks are, as their name suggests, ‘nice’. ‘Forgiving’ is probably a more appropriate term in that, as the API states, nice mocks will return 0false, or null for unexpected invocations. Meaning:

  • for methods that return intdoublelongcharfloatbyteshort (non\-boolean primitives) – the returned value is 0
  • for methods that return boolean (not sure about Boolean) – the returned value is false
  • for methods that return Object (or anything that extends Object) – the returned value is null

The benefits are not obvious without further explanation. Try to think of it in these terms. Nice mocks allow you to configure them the way you want for the behavior you care about without having to configure them for the behavior you don’t care about and are not relying on for your test. For example, let’s assume you want a mock for an object that has a getId() method. Chance are you don’t care what getId() does and if the code you’re testing doesn’t care what it does, but happens to call it in a log statement or something that is irrelevant to your test, then a nice mock will allow you to not have to setup an expectation for that method (see Example 1).

package com.partnet.foo;
public class Foo {
  private Emailer emailer;
  public void doSomethingCool() {
    // I don't care about this and don't want to setup an expectation for it
    log.debug("emailerId:" + emailer.getId());
    // something worthy of being unit tested
    emailer.sendEmail(...);
  }
}

Additionally, if another developer were to remove that log statement, the unit test wouldn’t have to change because the expectation was never added and the tests wouldn’t break just because a log statement was removed.

Prefer “Relaxed” Expectations

The term “relaxed” refers to the IExpectationSetters API as it relates to configuring the number of times an expectation is valid. Specifically, the methods once()times(count), and times(min, max) should be avoided unless you really care and/or your test relies on them. The methods anyTimes() and atLeastOnce() should be used instead. These “execution count” methods set the number of times a given method is expected to be called. The reason the latter methods should be preferred is that, while setting up explicit method call counts is certainly valid, implementations change over time and often times those changes have no effects on the functionality of a given object. For example, who cares how many times emailer.getId() is called in the above example and does the fact that it gets called multiple times have any effect on the calling code? Clearly not. However, if an expectation like the following was added:

EasyMock.expect(mockEmailer.getId()).andReturn(1).once();

and later the log statement was removed or an additional log statement was added that called getId() again, the unit test would fail.

However, this practice is not an across-the-board standard as it makes sense to setup an expectation like the following:

EasyMock.expect(mockEmailer.sendEmail(...)).andReturn(true).once();

because sending multiple emails is most likely not expected or okay.

Please note that not specifying one of the “execution count” methods is the same as using the once() method (i.e. once() is assumed unless otherwise instructed).

Stub Returns

andReturn() vs. andStubReturn()

EasyMockSupport

Introduced in version 2.5.2, EasyMockSupport is your friend. It saves you the trouble of having to call reset()replay(), and verify() on all your mock objects. As the javadoc shows, an example usage is as follows:

package com.partnet.foo;
public class TestFoo
  extends EasyMockSupport {  // this is key
  @Test
  public void test() {
    resetAll();  // reset all existing mocks
    // create mocks
    firstMock = createMock(A.class);
    secondMock = createMock(B.class);
    replayAll();  // put all mocks (new & existing) in replay mode
    // use mocks
    verifyAll();  // verify all mocks (new & existing)
  }

This is the second in my three-part EasyMock Fundamentals series. Please leave your questions or comments in the comment section below and be on the lookout for the final installment next week.

Quick Links

EasyMock Fundamentals — Part 1

EasyMock Fundamentals — Part 3

EasyMock Fundamentals — Part 1

High Tech In my three-part EasyMock Fundamentals series, I will take you through the ins and outs of the open source Java library. EasyMock can be used in conjunction with a unit testing framework, such as JUnit or TestNG, to facilitate better unit testing without all the 2nd degree dependency issues. EasyMock provides the means (through the use of mock objects) to specify the response that will be returned when the code being tested makes calls to external methods. This will allow the result of the unit test to be isolated from variables outside of the scope of the unit test code.

An Introduction to EasyMock Fundamentals

Refer to the official EasyMock documentation for more detailed explanation of the tool (latest as of this writing EasyMock3.1 Docs) including download, setup, and a brief usage example.

Please note that, for the sake of simplicity, not all the details of the code examples have been included.

Stubs vs. Mocks

An alternative to using a mock object is to create a stub object; a lightweight implementation of the interface for the external methods, that just return the expected response. These two approaches are best illustrated with an example.

Let us say you want to write a unit test for an object Foo that does something cool, doSomethingCool(), and uses another object, Emailer, to send emails while doing something cool as follows:

package com.partnet.foo;
public class Foo {
  private Emailer emailer;
  public Foo(Emailer emailer) {
    this.emailer = emailer;
  }
  public void doSomethingCool() {
    // something worthy of being unit tested
    emailer.sendEmail(...);
  }
}
package com.partnet.foo;
public interface Emailer {
  boolean sendEmail(...) throw EmailerException;
}

If you’re trying to test the doSomethingCool() method, you don’t want to, shouldn’t have to, and thankfully don’t need to worry about what emailer.sendEmail() does (assuming the implementation of the call has no impact on the code you’re testing of course).

The assumption here is that the real implementation of Emailer, say it’s called FancyEmailerImpl, is a non-simplistic object that may require some configuration or won’t work in a non-real environment. In this case you do not want to have to create a real FancyEmailerImpl and use it in your testing because again, what it does has no bearing on the code you’re actually trying to test.

Stub Objects

Using the stub object approach, you could create a stubbed-out/dummy version of Emailer like the following:

// stub object
package com.partnet.foo;

public StubEmailer
  implements Emailer
{
  public boolean sendEmail(...) throws EmailerException {
    return true;
  }
}

Simple, easy, done… right? Yep, you can now just setup your unit test as follows and test away:

// stub object use
package com.partnet.foo;

public TestFoo {
  @Test
  public void test() {
    Emailer stubEmailer = new StubEmailer();
    Foo myFoo = new Foo(stubEmailer);

    myFoo.doSomethingCool();
  }
}

The downside to this approach is that you end up building and maintaining a bunch of stub code. Additionally, stub code can be difficult to write as you get into stubbing out more complex objects that you want to test around. For example, if the code you’re testing sets an ID on your Emailer and later retrieves it via setId()/getId() methods, this behavior would need to be stubbed out correctly.

Mock Objects

The alternative to writing stubs is writing mocks, or more correctly, using a mock object library to create mock objects for you. EasyMock is such a library. The following demonstrates how to use EasyMock to mock out the Emailer from above.

// mock object example
package com.partnet.foo;

public TestFoo {
  @Test
  public void test() {
    Emailer mockEmailer = EasyMock.createMock(Emailer.class);
    Foo myFoo = new Foo(mockEmailer);

    myFoo.doSomethingCool();
  }
}

Simple, easy, no stub code to maintain. Even cooler is how you solve the problem mentioned above regarding setId()/getId(). This is where the concept of Expectations comes in (in terms of EasyMock, these are called IExpectationSetters). An Expectation is basically you telling a mock object how to behave and what you expect to happen when you run the unit test code: “When this happens, do this”, “When your getId() method is called, return this value”, “I expect that your setId() method will be called”. After your unit test code has run, you can then ask EasyMock to verify that everything you expected to happen actually occurred so that you can be assured your code does what you think it does.

Downloads

The latest EasyMock files can be downloaded from a link on the EasyMock Download page.

Integration

Add these to the classpath:

  • easymock.jar
  • cglib (2.2) – to perform class mocking
  • Objenesis (1.2) – to perform class mocking

Note that EasyMock only works with Java 1.5.0 and above.


This is the first in my three-part EasyMock Fundamentals series. Please leave your questions and comments in the comment section below and look for my next post next week.

Quick Links

EasyMock Fundamentals — Part 2

EasyMock Fundamentals — Part 3

Contracting Entry Requirements: Is it Time to Reconsider?

ChessA lot of concern has been raised recently among Acquisition professionals within the Federal Government over how sequestration and future budgets will impact Workforce development and sustainment. DOD has made progress in recent years with some serious initiatives fueled by the Defense Acquisition Workforce Development Fund and Congressional recognition that the contracting and pricing workforces need special care and attention in order to meet the dangers inherent in the demographic “bathtub” that will burst when over 40% of the experienced contracting workforce retires, leaving behind comparatively small numbers of mid-level experienced personnel. Work in progress will be completed and new Acquisitions started by less and less experienced people as the maturing workforce exits. One big question is, did DOD react soon enough to mitigate the problem or do we still need a means of attracting trainable and seasoned talent?

Will rethinking 1102 contracting entry requirements help or hinder?

I was all in favor of the Acquisition Corps and DAWIA back in the 1990s and I still am. One thing the draftsmen of DAWIA proposed that did not get incorporated into the program was a salary bump similar to what other professional series like engineers and lawyers get. Even though there are education requirements to get hired as an 1102 and continuing education requirements (that might actually start to get enforced), Contract Management is not considered “professional enough” to warrant extra pay. So to get in, you have to meet the DAWIA career field minimum education requirements whereas the Loggies will hire you without them—and either career field will pay you exactly the same.

Hired as an intern pre-DAWIA with a bachelor of arts in Anthropology, I feel my liberal arts education gave me a great foundation for being able to analyze, evaluate and connect concepts and techniques, creating a great foundation for Contracting as a career. But under today’s rules I would not have been hired and would not have contributed 33+ years to DOD in the Contracting field. I did get an MBA, using tuition assistance provided by my Agency and I did achieve Level III for Contracting under DAWIA when the program started. And I earned CPCM designation from NCMA, too. I’m just one example of the type of individual being passed over today.

Furthermore, the people who trained me did not, for the most part, have college degrees, but they knew their craft. From this we can infer that the principles of contracting are within the grasp of any thinking individual, especially when other trained individuals are there to help.

I was surprised when working at Defense Contract Management Agency HQ to find that DCMA field activities (which are all over the world) have difficulty hiring 1102s, especially those qualified to become Contracting Officers. Attaining certification after being hired was not the issue; meeting the entry-level bachelor’s degree and business course requirements proved to be the stumbling block for the available pool of applicants (oh, and by the way, an HR specialist decides if your business courses qualify or not).

Speaking of the HR element, if we are going to look at changing 1102 entry requirements we also need to look at who is doing the pre-screening to create the list of job candidates. HR Specialists can’t be expected to operate under instructions that are anything other than black and white. If they were capable of making judgment calls about what might work in a person’s experiences that could substitute for a college degree or business courses, they’d be 1102s.

I like the suggestion of requiring a bachelor’s degree and then setting a time limit for getting the 24 hours in business completed after a person is hired because the material covered in these courses will be helpful. One drawback: Interns have a 24-month time limit on getting their DAU courses and DAWIA certifications completed, too (I did my graduate work on my own time, so this is not an insurmountable conflict) but, having worked as an Acquisition Workforce Manager, I can tell you that the supervisors who have Interns in their organization often feel there is not enough time for on-the-job training and/or contributions to productivity for the seat the Intern occupies.

If new hires are required to get the college level business credits there will need to be some sort of support proffered. The question is, will tuition reimbursement be enough? Can we afford to have interns take these classes and their DAWIA classes on the clock? As anyone who has pursued higher education while holding down a full-time job – while learning a profession! – can attest, it is a big personal commitment. We may have to bite a bullet that represents nothing but school for Interns the first couple of years. What if we set the bar in a different place? How does 0 business hours to get hired, 12 hours of business courses to get certified at Level II and a total of 24 hours to get certified at Level III sound? Interns and journeymen could work at their own pace knowing these requirements are going to have to be met in the future and, when they get hired into a position where Level II or Level III are required they will still have 24 months to complete 12 course credits – plus the required DAWIA courses.

I also think we are missing the boat by not allowing senior, experienced contracting professionals from the private sector to enter the career field at a senior level without DAWIA certifications already completed. You cannot take DAU courses unless you are a Government employee, so how can you fulfill this requirement? Acquisition Workforce members can apply for course waivers through the Fulfillment Program, so why not external hires?

Is it time to rethink the entry-level requirements for the 1102 series? Can we improve the current situation by broadening the applicant pool? What are your thoughts on positive changes that can fill the bathtub with bright, knowledgeable Contracts professionals dedicated to preserving the integrity of the procurement process while making sensible decisions that meet mission needs and satisfy responsibilities toward the tax payer?

Improve Cybersecurity with Continuous Monitoring

CybersecurityCybersecurity has now superseded terrorism as our country’s #1 threat. The latest US Intelligence Community Worldwide Threat Assessment published March 13, 2013 states that:

“Threats are more diverse, interconnected, and viral than at any time in history. Attacks, which might involve cyber and financial weapons, can be deniable and unattributable. Destruction can be invisible, latent, and progressive.”

Both government and private-sector groups are trying to keep up with the rising threat levels, but the increasing threats are outpacing the current standard technologies. For years, we have relied on firewalls and encryption, making sure that data is protected as it flows through the internet and is then protected behind a firewall. All agencies and organizations are being challenged with pressure to “do more with less” and reduce their personnel levels. In addition, new regulations are requiring high levels of documentation and reporting. The solution to this dilemma is the 24×7 nature of continuous monitoring (CM) and diagnostics. Continuous monitoring enables information security professionals and others to see a continuous stream of near real-time snapshots of the state of risk to their security, data, network, end points, and even cloud devices and applications.

Benefits of Continuous Monitoring

  • CM gives you situational awareness through full-network visibility. Real-time monitoring of account activity, sensitive data movement, malware and threats are equally important components of the continuous monitoring process.
  • CM is a key means for mitigating risk by allowing you to assess the effectiveness of controls and detect associated risk issues.
  • CM allows you to capture potential non-compliance early within the network, because not all threats come from the outside. Credit card processing, medical billing and even “Easy Pass” Toll systems use CM to catch duplicate and/or erroneous transactions.

Challenges of Continuous Monitoring

  • Because not all parts of an organization will understand the benefits of the effort, you will probably need a high-level sponsor.

Like with all technology-related improvements, CM implementations require investment. Many organizations demand a quantified return on investment (ROI) before implementation of a new IT system. However, cybersecurity has become such a pervasive threat and a desire for constant innovation oftentimes overshadows that ROI question because it is just the right thing to do.

Do you have experience with continuous monitoring? Share it with us below or simply share your thoughts and concerns on the topic.

Utah Getting Act Together on Healthcare IT Security

Healthcare Medical RecordsHealthcare IT security has been a sensitive subject for the past 12 months in Utah’s healthcare community with two major healthcare security breaches, but it looks like they are beginning to get their act together. The state has taken action to beef up security practices in the state to prevent future security breaches. Governor Gary Herbert recently signed a bill that creates a security office within the Utah Department of Health. The bill provides funding to support a staff dedicated to security and privacy work. The new group will review and audit technology projects within the Utah Health Department, making sure healthcare security and privacy are made a high priority.

Key Healthcare IT Security Areas of Weakness

An internal audit conducted last year found the following key areas of weakness. These areas will be the top priority for the new security team.

  • Data risk assessment and classification
  • Vendor Management
  • Data security procedures and training
  • Systems development, life-cycle and change management
  • Contingency and disaster planning
  • Governance

As the banking system has tightened their security and privacy requirements over the last few years, cyber-criminals have turned their focus to the Health Care industry. Healthcare identity fraud has become their number one target. Three percent of health care costs in the U.S.—the equivalent of $78 billion—can be attributed to medical fraud.  Without a doubt, health care organizations across the country should be following Utah’s lead in establishing dedicated security offices, reviewing all IT projects that handle personal data and ensuring that HIPAA rules are followed in their entirety.

Here at Partnet, we work hard at keeping government eCommerce sites safe and secure. We commend the State of Utah for taking swift action to protect the citizens of Utah by putting the right security measures in place to prevent further healthcare security breaches.

4 eCommerce Content Do’s

Ecommerce SiteCommerce is simply buying and selling with an emphasis on doing so on a large-scale. eCommerce, then, is the conduct of this activity in an online or e-(electronic) environment. “Large-scale” is illustrated by behemoth eTailers like Amazon, Zappos, DOD EMALL, eBay and GSA Advantage. In the early days of eCommerce there was an “If you build it, they will come” mentality. This worked for a while, in part due to curiosity over new technology and often because there was something available that was truly interesting. I’m sure you’ve already noticed a real element of chicken-or-egg involved here. If you don’t have products of interest, customers will not come to your site, but if you don’t have customers, it’s hard to convince purveyors of products to take a business risk on you.

As it goes, those early days are over and all of the dust has pretty well settled. A survey of the top eCommerce platforms indicates that there are two main areas that you must get right to get to the top and stay there: performance—as discussed in my last blog post—and content. Today I’ll address content. As I mentioned in my previous blog, if you leave out half of the equation, you are essentially multiplying the half you do have by zero. More concisely put: leave out even one, and you’ve got nothing. Putting your time into improving performance for your customers is futile unless you’ve also considered content.

Four eCommerce Content Do’s

One important aspect of content that I’ll touch on first is richness. If people are unable to use their physical senses to understand a product, they’ll need another means of understanding just what that product is in order to know that they want it . Visual and textual information that aid the consumer in envisioning themselves holding or using what you are selling is vital. Including a product image is a given but please don’t stop there. Make sure you have details like dimensions, weight, materials and suggested uses—anything that will help to create a full, rich picture in your customer’s mind. Probably one of best providers of this is the opinions of others. Being able to read about the experience of others is the fastest way for your customers to see themselves in the same shoes and, ultimately, start the check-out process.

When it comes to content, please also address quantity. If you offer a product line, be sure to offer the full product line and associated products. It’s a competitive eWorld out there. When shipping costs are free or start to become lower when amortized across several items, customers are more likely to submit that shopping cart as an order. If they can’t find everything they are looking for, a one-stop shop so to speak, they are likely to go looking elsewhere to either minimize their shipping expense or simplify order tracking.

Now that you have lots of rich content, you also want to start thinking of all that rich content as an asset. It is extremely valuable. Others will want it. You need to develop strategies that either leverage or protect that data to your best advantage. There’s nothing wrong with sharing as long as you are getting equal value back from the arrangement.

The last content tip that I want to touch on is grooming your content for success by selecting and following a data standard. A data standard is going to help you organize your content in a meaningful way and point out gaps that should be filled. Once you have standardized your content using a vetted approach such as G1 or ECCMA, you have added two more items of value to your content: the ability to mine the data effectively with business analytics tools and portability of your content to wherever you want it to go.

Remember, it’s no longer the early days of eCommerce, so it is imperative that you hone your strategy when it comes to buying and selling. Keeping these four Do’s in mind as you build or improve your content will help you and your site thrive in this competitive eCommerce arena. So, what do you say; what are some of your eCommerce musts?

 


In case you missed it, be sure to read the first in my two-part eCommerce series: 3 eCommerce Mistakes You’re Making. Never miss a post again; subscribe to TurnLevel to receive blog posts right to your email inbox. It’s easy and it’s free.