Monday 13 June 2022

How to get a FedEx testing tracking number?

The short answer (detailed answer below)

To get one of the testing FedEx tracking numbers, you can use one of the tracking numbers from the table below (copied from Mock Tracking Numbers for FedEx Express and FedEx Ground) or the number 123456789012.

Note that the FedEx Sandbox environment might be unstable during your testing and you might need to use FedEx API mocks instead (either built in-house using Wiremock or ready-made by a vendor).

Scan EventTracking NumberTrack By Reference Info.Shipment Account NumberShip DateDestination Postal Code
Shipment information sent to FedEx449044304137821Customer Reference: 115380173Ground Shipment ID: DMWsGWdnNN51008800015-08-202033126
Tendered149331877648230Ground Shipment ID: 14933187764823051008800015-08-202028752
Picked up020207021381215Ground Shipment ID: 5308952851008800015-08-202030549
Arrived at FedEx location403934084723025Ground Shipment ID: 403934084723025Department: 3182672251008800015-08-202099206
At local FedEx facility920241085725456Customer Reference: 0014243047/34684523 Ground Shipment ID: 92024108572545651008800015-08-202019720
At destination sort facility568838414941Shipper Reference: P218101_004154359Purchase Order: P218101_00415435951008800015-08-202085388
Departed FedEx location039813852990618Customer Reference: 4631962Ground Shipment ID: THE HOUSEDepartment: McGeePurchase Order: 338515851008800015-08-202024740
On FedEx vehicle for delivery231300687629630Customer Reference: W62283340102Ground Shipment ID: 231300687629630Purchase Order: 622833451008800015-08-202033126
International shipment release797806677146N/A
Customer not available or business closed (Delivery Exception 007)377101283611590Ground Shipment ID: 37710128361159051008800015-08-202095815
Local delivery restriction (Delivery Exception 083)852426136339213Customer Reference: 11840271301351008800015-08-202011375
Incorrect address (Delivery Exception 03)797615467620Shipper Reference: OTHER-TK10451008800015-08-202070810
Unable to deliver (Shipment Exception 099)957794015041323N/A
Returned to sender/shipper076288115212522Invoice: 8190951008800015-08-202050323
Clearance delay (International)581190049992N/A
Delivered122816215025810Customer Reference: PO#17472451008800015-08-202024273
Hold at location843119172384577N/A
Shipment canceled070358180009382Customer Reference: 15241402Ground Shipment ID: 07035818000938251008800015-08-202094545
Duplicate Tracking Number713062653486Unique Identifier 1: 2457821000~713062653486~FXUnique Identifier 2: 2457835000~713062653486~FX

The longer answer

The FedEx Sandbox has numerous stability and test data problems. For example, if you use tracking code 123456789012, you will get a different response status depending on the state of the FedEx Sandbox environment.

If you are performing a one-off manual test of your Magento integration with FedEx API, then using the FedEx Sandbox should be sufficient, and you can go ahead and use one of the codes provided above.

If, however, you are running automated regression or integration tests on a schedule or per commit, then the instability of the environment might cripple your testing. For example, you might see flaky tests and flaky builds and have to spend time investigating them even though there is nothing wrong with your code or tests; it's just an issue with the FedEx Sandbox API.

To resolve the issue with FedEx Sandbox environment stability, you have three options, which are essentially about using test-doubles instead of the real FedEx Sandbox API:

  • Create and use mocks in your code instead of using the FedEx Sandbox. For example, Mockito in Java or uniuttest.mock in Python. This means you will have to write the FedEx Mockito mocks yourself. And it comes with several tradeoffs. This is a popular option for developers that have time on their hands and can build solutions internally, and don't work on a tight deadline.
  • Create over-the-wire mocks with tools like Wiremock or Mountebank instead of using the FedEx Sandbox. There is a list of tools like that on Wikipedia. The issue here again is that you have to build those over-the-wire mocks yourself, which can be problematic if it's more than one API and you have a lot of work on your plate anyway.
  • Use ready-made FedEx API mocks like the one from Traffic Parrot instead of using the FedEx Sandbox. The advantage is that experts create them and can use them within minutes. Just copy their mock API URL and use it instead of the FedEx one. Good idea if you are on a tight deadline. You will have to pay for using them, which can sometimes be a downside of this option.

enter image description here

Wednesday 8 June 2022

Avoid production data in test environments!

As ThoughtWorks have observed in 2021, using production test data in test environments has significant risks and drawbacks, for example:

  • test environments have lower security constraints than production environments, so they expose client data to threats
  • incorrect email test alerts sent to real users 
  • obfuscation often only addresses parts of the data sets
  • copying data can infringe on data protection laws
One way our customers avoid having to copy production data into the test environment is by using synthetic data created in virtual services, or API mocks in our commercial tool Traffic Parrot and a combination of open-source tools like Wiremock or Mountebank.

This often requires an upfront investment to define user personas that can be reused across test cases but removes the risks listed above. It also allows for increased test coverage and enables automated testing. 

As one of our customers put it:

"We have used Traffic Parrot to simulate third-party HTTP services and test our product in isolation. Traffic Parrot consultants have developed custom-made simulators for us. During the first testing cycle, it allowed us to find 28 issues with our product’s release candidate and fix them early in the software lifecycle. This means completing the testing schedule more than 2 months earlier than anticipated just for the first release alone.
We have also used Traffic Parrot to create third party system simulators that communicate over IBM MQ queues. The previous process took at least 30 minutes of manual effort per test case to verify when the interface was available—and sometimes up to 3 days when testing needed to be scheduled with external teams. Our Traffic Parrot simulators respond within milliseconds and are always up. They enabled our team to create automated tests that rely on those service responses and meet our department automated testing KPIs. This allowed us to reduce the regression testing cycle from 30 days to a week."
QA Director working for a software company responsible for government projects

If you would like to see what would be the Return On Investment (ROI) for your team for switching from using production data in test environments to service virtualization and API mocking, please reach out to us.

Self-service service virtualization tool for platform engineering product teams

As Thoughtworks have observed, platform engineering product teams are a sensible default to delivering results to customers in competitive fast-paced environments.

"The emphasis here is on API-driven self-service and supporting tools, with delivery teams still responsible for supporting what they deploy onto the platform. Organizations that consider establishing such a platform team should be very cautious not to accidentally create a separate DevOps team, nor should they simply relabel their existing hosting and operations structure as a platform."  - ThoughtWorks Technology Radar 2017 edition

Commercial tool Traffic Parrot and opensource tools like Wiremock or Mountebank are compatible with self-service teams where there is no centralised admin team managing the service virtualization and API mocking infrastructure. The cross-functional product teams manage Traffic Parrot instances and mocks themselves for their product needs.

As one of our customers put it back in 2017:

'We are building a new platform based on microservices and needed a testing infrastructure that allowed all of our testers to work autonomously, using local machines to record their communication streams between their services and inside our pipelines in order to virtualize a service. Traffic Parrot, while not as fully featured as offerings from HP and IBM, offered the key capabilities that our teams needed such as HTTPS and JMS IBM MQ and a substantially smaller footprint that allowed it to run locally. We have been very pleased by Traffic Parrot's email support and responsiveness to our requests and would recommend them to other teams doing microservice-based architectures."Chief Architect at a Fortune 500 company

And another team that migrated off a centrally managed solution:

"We have migrated our department off CA Lisa to reduce our operational costs in performance and system testing environments. We used WireMock for HTTP stubbing and mocking and Traffic Parrot for IBM MQ. Neither WireMock nor Traffic Parrot provides all the features available in CA Lisa. Still, after initial proof of concept assessment, we have decided those tools' feature sets will be sufficient for our needs and significantly cut costs. It took our team six months to migrate HTTP to WireMock and another three months working closely with the Traffic Parrot team to improve their offering to meet our load testing and mainframe integration requirements. With this investment, we cut our tooling costs in half." - Executive working for a global retail bank.

If you currently use WireMock or Mountebank but need gRPC, JMS, ActiveMQ, RabbitMQ, IBM® WebSphere MQ 7.5+, AMQP, or other protocol support, let’s schedule a 20-minute call to explore if Traffic Parrot is a better fit for your needs.

Friday 3 June 2022

Traffic Parrot 5.33.11 released, what's new?

We have just released version 5.33.11. Here is a list of the changes that came with the release:


  • Added access logging for UI interactions, written to logs/http-ui-access/http-ui-access-yyyy_mm_dd.log


  • Upgraded bundled JRE from 8u282 to 8u332
  • Upgraded gRPC from 1.43.1 to 1.46.0
  • Upgraded protoc from 3.19.1 to 3.20.1
  • Upgraded WireMock from 2.31.0 to 2.33.2
  • HTTP VS access logs are now written to logs/http-vs-access/http-vs-access-yyyy_mm_dd.log
  • Upgraded Gradle version in examples project from 4.10.1 to 7.4.2
  • Logs file listing in UI is now ordered by last modified date


  • Library upgrades to fix OWASP issues