One of the patterns that I've pushed over the years and with the various companies I've assisted is testing the edges, or Boundary Testing.

The term Boundary Testing can encompass many things. The simplest definition I've seen is ...

Boundary testing is the process of testing between extreme ends or boundaries between partitions of the input values. So these extreme ends like Start- End, Lower- Upper, Maximum-Minimum, Just Inside-Just Outside values are called boundary values and the testing is called "boundary testing."
Boundary Value Analysis and Equivalence Partitioning Testing

However, the testing that I want to encompass takes this concept a bit further. What I would like to see tested are the edges of the system(s).

Third-Party Use-Cases

Say our code has imported moment.js and we use this code to convert a UTC date/time into a local time.

<script src="https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.22.2/moment.min.js"></script>
<script>
  var date = moment.utc().format();
  console.log(date, "- now in UTC"); 

  var local = moment.utc(date).local().format('hh:mm:ss a');
  console.log(local, "- UTC now to local"); 
</script>

I would want some unit test that verifies the outcome of local. In this way, if moment.js changes or upgrades down-the-road, the test will start to fail.

This shows a breakage at this boundary.

It has been suggested to me in the past that this code has its own set of unit-tests and that we should expect the functionality above to work. My point has been that I want an "edge" test against an upgrade or change in this particular functionality to future-proof the code.

APIs that Trigger Processes

In the particular case I have in mind, a post to an API (let's call it /arrived) triggers a device Notification to several store devices. The employees can click the Notification and see the data in our application.

As it was originally designed, the post to the API simply returned a 200/OK if the Notification was successfully sent.

The issue came in when lastName changed to customerName and one of these APIs was not changed. The only way to see what was sent to the application via Notification was to trap the logs within the application on an actual device.

It occurred to me that the solution, allowing better diagnostics and the ability to test the data load, was to include the Notification payload in the API response.

// API PATH: /trigger-notification
// Sending the following to the API ...
{
    "storeNumber": "1111",
    "orderID": "22222222222",
    "customerName": "Bob Fornal",
    "vehicleType": "Ram 1500",
    "vehicleColor": "Silver",
}
// Returns the following ...
{
    "message": "Send store notification success.",
    "status": "OK"
}

The returned body on a 200/OK tells us nothing about the inner workings of this API.

However, with the notification data included in the response above, like this ...

// Should Return ...
{
 "message": "Send store notification success.",
 "status": "OK",

 "notificationDetail": {
  "additionalParams": {
   "customerName": "Bob Fornal",
   "orderId": "22222222222",
   "arrivalTime": "2021-01-27T03:12Z",
   "specialInstructions": "Testing Order",
   "vehicleColorAndType": "Silver Ram 1500"
  },
  "aps": {
   "alert": {
    "body": "Customer Name: Bob Fornal\nOrder #: 22222222222\nVehicle: Silver Ram 1500\n"
   },
   "sound": "alert.wav",
   "content-available": 1
  }
 }

Now provides a solid tool to test and diagnose in an area where things were brittle.