Browse by Category

B2G Communication Mismatch

B2G CommunicationBusiness-to-Government has experienced a few bumps in the road over the past year: the GSA conference scandal, the Sequester restriction on training and travel budgets, the government program office’s reluctance to speak with industry, and now the government shut down. Indeed so much has happened in government over the last year to increase the challenge of B2G communications that I’d be hard-pressed to list it all. The folks over at Market Connections Inc and Boscobel Marketing Communications have published a white paper which sheds some light on the communication dilemma we are facing today and discusses the apparent mismatch of how industry and the government plan to communicate with each other under the current budget constraints. Let’s discuss some of the more interesting points they’ve presented.

The Difficulties of Talking to Your Government Customer

Seventy-two percent of agencies plan to attend fewer conferences and 57% say they will be hosting fewer conferences. Contractors are in step with these results with 50% stating they will attend fewer conferences. Government participants stated they would be turning more to webinars, reading publications in their field, and reviewing websites to gain knowledge. Contractors plan to have more personal discussions with government personnel in addition to updating their websites and producing white papers and case studies. The biggest discrepancy was in the area of face-to-face visits. Of contractors, 68% said they would try to do more face-to-face visits, while only 19% of government said they planned to do the same. This might explain why it is so hard to get an appointment to meet with government personnel.

A silver lining does appear in the findings however, especially for small businesses. Increased use of social media and website reviews by government personnel will make it easier for small business to get their story out and compete directly with large businesses. By participating in LinkedIn discussions, regularly using Facebook, Twitter, and Google+, you can spread your message to government and become known as a thought leader. Video is also a great way to highlight your products and explain what you can bring to your customers.

A big concern held by both government and industry is that this communication mismatch will inhibit innovation and collaboration. Two-thirds of both contractors and government agree that it will be difficult for government to maintain best practices. Three-quarters of those surveyed, for example,  believe contractors will have to become more innovative to inform and educate their government customers. As contractors we must keep trying to attract their attention in new and creative ways as well as the tried-and-true approaches like simply knocking on their door.

A Look Back: eBusiness Retrospective Part II

Old ComputerLast week we took a stroll down DLA memory lane and the evolution of eBusiness with A Look Back: eBusiness Retrospective. This week let’s take a look at how the DLA leveraged technology to support business processes in the post-Internet era.

Enter the Internet. The concept of AUTODIN was harnessed for much broader use both in who would use it and what would be transferred across it. Email was the first thing most people encountered that got them on the World Wide Web. Then a colleague showed me how you could look stuff up using something called AltaVista. (If you’re wondering what happened to those early search engines, read more here.) With the Internet you could send large files to other people using “ftp” (this was the first time I remember using lower case letters for an acronym). And then another miracle happened: two people could look at the same thing on the Internet at the same time.

Smart people in DOD realized that we needed a concerted effort to get the best from this new, amazing resource that we now take as a given here in the 21st Century. The Joint Electronic Commerce Program Office was established with Scottie Knott at the helm. From this think-tank-with-an-action-plan came such web-based systems that have become a familiar part of the landscape like Wide Area Workflow, used for invoices, material inspection and receiving reports; DOD EMALL, the one-stop eCommerce site for DOD; Contractor Central Registry, where all vendors doing business with the government have to be registered; Electronic Document Access, which holds a copy of all DOD contract documentation; and FedBizOpps, which advertises opportunities from the government to the vendor community. With that, eBusiness was born.

So where to go next? Everyone’s money is on mobile technology and I hope that’s where we go. Talk about bringing the power of computing right to the person doing the work! Mobile computing does one better by bringing the power of computing to the person doing the work WHERE the work is being done. I don’t know who will be reminiscing about the early days of mobile computing in 20 years from now, but I’m sure it will make computer users of the time smile.

A Look Back: eBusiness Retrospective

Relic ComputersRecently my friend and colleague Claudia “Scottie” Knott was inducted into the DLA Hall of Fame. This got me thinking about where she and I were in our careers when we met in the early 1980s. As everyone knows, the Department of Defense has always been an information technology leader and was an early participant in the development of the Internet. Leveraging the ability to make information, communications, and transactions available on a broad scale has had a positive impact on DOD business processes. I’m happy to say that Scottie and I were a part of that evolution at DLA and had big dreams for leveraging technology to support business processes—what we now call eBusiness. Today I’ll give you a look at this evolution up until the time of the Internet. Next week, we’ll continue the discussion with the significant innovations brought about in the post-Internet age.

Life before Big Data: Pre-Internet Times

Originally, data processing was accomplished on a local level. If two organizations needed to share data, they hand delivered or mailed completed forms to each other. Data had to be manually entered at each location where a computer would then process it to produce the desired effect (e.g., create paychecks, release stock from a warehouse, or bill a customer). Besides the duplicate labor, the margin for error was increased each time the data had to pass through another pair of Punched Tapehands to be processed. Punched cards were a great innovation. With punched cards, the margin of error was reduced because one computer could punch the card and the next computer could read the card, successfully preserving the information for data processing. This translated into measurable savings. But they had to be kept in a specific order for the computer to read the cards properly (think major disaster if a box was dropped) and they still had to be mailed (think slow, not to mention possibly damaged or lost). Even magnetic tape had to be mailed if another computer elsewhere needed the data to perform its job.

The next innovation for DOD was AUTODIN, the AUTOmatic DIgital Network. AUTODIN eliminated the mail and made worldwide data sharing a reality. Originally AUTODIN ran on second generation computers that used semiconductors instead of vacuum tubes. These computers occupied a large amount of space and required a LOT of air conditioning. (Read more about that here.) What was practically miraculous about AUTODIN was that it made point-to-point transaction processing a reality. It was Electronic Data Interchange before the term was coined. DOD was stepping up its eBusiness game as early as the 1960s, when AUTODIN first went live.

Computer ThrowbackAUTODIN solved the problem of transferring massive amounts of data in less than 24 hours between two computer systems that were far apart, but the language of AUTODIN was bound by 80 card columns. The precise position of a letter, number, or blank in those 80 spaces communicated enough information to convey—in the case of a requisition for supplies, for example—what was needed, who needed it, how much of it was needed, where it was to be sent, and who would pay for it. In order to accomplish this, an intricate series of codes was developed so that one or a few characters could convey a lot of information. Think about your 140 character limit on Twitter for a moment! In order to communicate via AUTODIN you needed a big manual with formats, codes, and dictionaries, so it was not very accessible; if you didn’t need to work with it, it wasn’t worth learning.

“Dumb terminals” were the next big advancement where regular workers could send inquiries to their local mainframe to get the latest, as of last night’s cycle, information about a contract, an account, the quantity of stock on hand, or a personnel status. These terminals were shared, often among a hundred people or so. And competition for a seat at one could be fierce. While these tools brought the power of computing closer to individual workers, there was still a long way to go to get to eBusiness.

When the first personal computers (we actually said the whole thing at first, not just “PC”), showed up in the office, they went into a room that could be locked at night. There was one (1) per Division. We could create graphs and print them right on the transparencies. It was very exciting. If the boss wanted to change it, you just printed a new one! We used patterns in the bars and pie sections and symbols on the data points for line graphs because we didn’t have color printers at the time.

In the 1980s there was a lot of local creativity going on throughout DOD. People saw new technology, like PCs, and came up with some pretty creative ways to use it. Scottie Knott impressed us all with leveraging downloaded mainframe data into a PC word processor to produce action sheets for contract administrators. I don’t think that little program—what we might call an app today—was mentioned in the write up for her Hall of Fame citation. Nonetheless, PCs allowed us to move from writing elaborate requests for programming, to ordering a download we could manipulate on a PC ourselves. The power of computing moved one step closer to the people doing the work and eBusiness was beginning.

I also worked with Scottie on the DLA Pre-Award Contracting System (DPACS). The objective of this system was to eliminate mainframe paper output by delivering it electronically to the desktops of the buyers. Programs, not yet apps, assisted the buyers in tracking workload, creating and distributing documents, recording activity and results, and finalizing procurement actions. You have to understand that this was truly a novel concept. It was met with a lot of skepticism and the budgeteers were having a very hard time with the expense of putting a PC on everyone’s desk. This was a client-server application which meant a lot of downloading and uploading to get and send data to the mainframe, but we could actually see the drop in paper consumption and, as the learning curve was overcome, an increase in productivity. While the mainframe remained the backbone and was updated only every 24 hours, client server activity could happen in real time—another ground breaker for eBusiness.

Next week we will discuss all of the changes that we experienced in the post-Internet age. So what about you? Do you remember punched cards and magnetic tape? What’s your favorite technology throwback? Add your comments below.

Government eCommerce: A Proposal for Austere Times

Cracked EggI think it’s time for another leap forward in how the Government approaches acquiring supplies. The commercial sector is replete with much of the stuff that supports business (office) operations. It has become accepted that Government warehouses stocked with these materials are not needed to ensure the smooth performance of daily operations. A lot of the acquisition of these goods is done outside the officially sanctioned Federal Government eCommerce sites. The US Government is losing visibility of where the money is going instead of channeling the business into its own transparent, made-to-suit Internet capabilities. Opportunity for intensely leveraged prices, streamlined business processes and strategic sourcing are being lost daily. Let’s just take one small leap this year and install customer product review capability in our Government on-line ordering platforms.

If we’re in the mood for more than that, here is another suggestion:

Only companies with a US Government contract are allowed to vie for the Government Purchase Card (GPC) business online within officially sanctioned US Government websites (e.g., DOD EMALL and GSA Advantage). At the same time, GPC holders can walk into any brick-and-mortar location to select items off the shelf at will or visit any commercial website and click with abandon. Commercial terms and warranties are completely acceptable when no one is looking evidently. The US Government needs to capture that walk-in business on its own eCommerce platforms for three reasons:

  • The data being collected on Government Purchase Card (GPC) usage is murky and incomplete. By consolidating GPC activity to officially sanctioned Government owned and operated eCommerce sites transparency on GPC usage can be achieved.
  • Compliance with laws and regulations concerning mandatory sources and socioeconomic program support can be monitored and enforced.
  • Channeling this tremendous volume of supplies will allow the Government to begin to strategically source material in unprecedented ways. In fiscal year 12 DOD EMALL had $86 million in office supply sales and nearly $10 million in electronics. We don’t know what the sales in these categories are for brick-and-mortar purchases or commercial websites, but imagine the prices you could command if all this business were fed through one or two made-for-Government channels!

So how do we make that happen? I see two options: one I’ll call “Quick” and the other I’ll call “Better.”

The Quick option would be to allow all comers to enter the Federal marketplace limited only by the GPC of the person ordering instead of insisting on a contract (which is expensive for many of these vendors to acquire and carries administrative costs for the Government). This does not violate what GPC holders are already allowed to do outside of the Federal marketplace and has the added bonus of vendor “natural selection” based on GPC holder choices.

The Better option would be to select only 3 vendors for long term contracts in each major category and guarantee that business to them for the length of the contract. Once the prices offered in the Federal marketplace really do beat what you can find on the open market GPC holders will want to trade there.

Both solutions require one more thing: a mandate that the Federally sanctioned web ordering capabilities be used by GPC holders for certain classes of supplies to the exclusion of brick-and-mortar and commercial web sites. We’ll discuss that in my next blog post.

eCommerce for Government IS Different

Government eCommerceI’ve heard a lot of discussion lately in our office asking the question, why can’t government eCommerce be more like Amazon? Better yet: why can’t the government just use Amazon? But there are differences between commercial eCommerce websites and government websites and for good reason. The differences between government eCommerce and eCommerce for commercial business might be difficult to notice at first glance, but these differences are key to a successful government eCommerce solution.

Amazon’s mission statement is: “to be earth’s most customer-centric company; to build a place where people can come to find and discover anything they might want to buy online.” Basically to part people from their money and while making a profit. Sure there is a good dose of customer service in there, with quick delivery and easy returns, but all that just points to their bottom line: profit.

Government is not a commercial business and it shouldn’t be treated that way. The mission of the government website is to support the war fighter or other government personnel with the products they need at the least cost to the taxpayer.

So why would you choose an eCommerce solution for government that’s designed for commercial business? You shouldn’t, and this is why:

  • An eCommerce solution protects the integrity of government by providing oversight.
  • It prevents malfeasance by utilizing Internal Controls.
  • Weak or exposed areas are mitigated by Risk Management.
  • It helps the government prepare for oversight with Self Auditing / Audit Readiness.

Differentiating Capabilities for Government eCommerce

The differences between government eCommerce and eCommerce for commercial business might be difficult to notice at first glance, but these differences are key to a successful government eCommerce solution.

• Rules-based capabilities allow your work to guide your choices and options.
• Interaction with accounting systems provides data quality where it matters most.
• Workflows for pre-purchase approvals support authority boundaries.
• Vendor contract management tools help with monitoring.
• Auditing for inappropriate purchases keeps the business process honest.

Sure government eCommerce sites could learn a thing or two from Amazon about product descriptions and shipment status, but the government really is a different animal and should be considered as such.  What do you think about the difference between commercial and government eCommerce.  Join the conversation at Turnlevel.com.

Customers Voice High Praise for DOD EMALL

Thumbs UpThe DOD EMALL Program Office at the Defense Logistics Agency Headquarters recently sent a survey to customers asking the impact to their mission if DOD EMALL were no longer available. The application received high praise from the users. Here are just a few of their responses.

DLA Land and Maritime

“If we were to lose access to DOD EMALL Tire corridor, it would have a significant negative effect. Currently we use the website to validate NSN’s sources of supply for all DOD buyers and we provide our customers with validated spec sheets that they can use to verify the accuracy of the product they have received. There is no other database that will give me this ability. I am in that database every day reviewing, updating or retrieving data for a customer or a buyer. This section of the DOD EMALL has allowed other organization (TARDEC/TACOM) to easily assist with research and identify inconstancies with the data so that I can properly maintain the NSN’s through the cataloging actions. This is the best way for all organizations to see the same information on one system.”

DLA HQ

“It would make a big impact, I support 26 offices, so it would slow down our supply for the DLA offices I support.”

Magellan Aerospace

As a broad stroke perspective from Procurement, lead time would be the greatest impact to our delivery schedule. The material purchased through DOD EMALL is not readily available on the open market or the OEM in most instances. GEAE is our main repair line, lead times ranging up to 725 days.”

USAF AFMC – Robins Air Force Base

“EMALL is very important to us at the F-15 SPO. We have a contract with Korean Air Lines (KAL) to complete the Programmed Depot Maintenance (PDM) on the USAF F-15s stationed at Kadena AS, Okinawa, Japan. KAL has the responsibility of obtaining approximately $300k per aircraft of contractor furnished material (CFM) which is managed by DLA. We, the F-15 SPO, use DOD EMALL to assist KAL in obtaining assets needed when they are having problems, especially “Hot Items”, items if not received could delay the PDM process. Without EMALL, the F-15 SPO would not have visibility of KAL’s requisitions or asset availability. This would limit our ability to assist KAL in obtaining needed assets greatly, especially due to the 13 hour time difference from WRALC to Korea. We submit SARs when necessary and receive notices when KAL has submitted a SAR. We use the notes section when there are zero assets availability to get information concerning contract issues and delivery issues. To sum it up, if EMALL went away, the USAF F-15 PDM Program at KAL would suffer tremendously. “

Partnet is the the principle developer of the DOD EMALL, and as such it is nice to know that our hard work is appreciated. The DOD EMALL is available for use by DOD and Federal Agency employees, PBL/CLS contractors and State and Local governments. Have you tried DOD EMALL yet?

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.