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 Event	Tracking Number	Track By Reference Info.	Shipment Account Number	Ship Date	Destination Postal Code
Shipment information sent to FedEx	449044304137821	Customer Reference: 115380173Ground Shipment ID: DMWsGWdnNN	510088000	15-08-2020	33126
Tendered	149331877648230	Ground Shipment ID: 149331877648230	510088000	15-08-2020	28752
Picked up	020207021381215	Ground Shipment ID: 53089528	510088000	15-08-2020	30549
Arrived at FedEx location	403934084723025	Ground Shipment ID: 403934084723025Department: 31826722	510088000	15-08-2020	99206
At local FedEx facility	920241085725456	Customer Reference: 0014243047/34684523 Ground Shipment ID: 920241085725456	510088000	15-08-2020	19720
At destination sort facility	568838414941	Shipper Reference: P218101_004154359Purchase Order: P218101_004154359	510088000	15-08-2020	85388
Departed FedEx location	039813852990618	Customer Reference: 4631962Ground Shipment ID: THE HOUSEDepartment: McGeePurchase Order: 3385158	510088000	15-08-2020	24740
On FedEx vehicle for delivery	231300687629630	Customer Reference: W62283340102Ground Shipment ID: 231300687629630Purchase Order: 6228334	510088000	15-08-2020	33126
International shipment release	797806677146	N/A
Customer not available or business closed (Delivery Exception 007)	377101283611590	Ground Shipment ID: 377101283611590	510088000	15-08-2020	95815
Local delivery restriction (Delivery Exception 083)	852426136339213	Customer Reference: 118402713013	510088000	15-08-2020	11375
Incorrect address (Delivery Exception 03)	797615467620	Shipper Reference: OTHER-TK104	510088000	15-08-2020	70810
Unable to deliver (Shipment Exception 099)	957794015041323	N/A
Returned to sender/shipper	076288115212522	Invoice: 81909	510088000	15-08-2020	50323
Clearance delay (International)	581190049992	N/A
Delivered	122816215025810	Customer Reference: PO#174724	510088000	15-08-2020	24273
Hold at location	843119172384577	N/A
Shipment canceled	070358180009382	Customer Reference: 15241402Ground Shipment ID: 070358180009382	510088000	15-08-2020	94545
Duplicate Tracking Number	713062653486	Unique 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.

Start your free 3-day trial now!

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.

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:

Features

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

Changes

• 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

Fixes

• Library upgrades to fix OWASP issues