If I were building a simple function that divided one number by another, I would:

1. In all cases, call the function. The first test would probably be a happy path, like `10 / 2`.
2. Another test would divide a smaller number by a larger one, resulting in a decimal value.
3. Some other tests would introduce negative numbers into the mix.
4. Finally, I would be sure to have one test that divided by zero, to see how that was handled.

I have a series of modals in React that I need to test. They have some commonalities:

1. They receive a set of props.
2. They act on those props to display a bunch of elements to the user, pre-populating these elements with some combination of the data in the props.
3. They use the `fireEvent.###` functions to simulate what the user would do within the modal.
4. Near the end of each test that involves a POST or a PATCH, a `Submit` button is pressed.
5. After pressing the `Submit` button, I have two `expect` functions at the end of each test, like in these examples:

```
expect(spy).toHaveBeenCalledTimes(1);

expect(spy).toHaveBeenCalledWith({
  type: 'SOME_ACTION',
  payload: {
    property1: 'Some value',
    property2: 'Some other value',
    property3: 53.2
  },
});

```

This approach entirely makes sense to me because, much like a simple math function, the modal has data coming in and data going out. But some colleagues are insisting that we shouldn't be testing with such `expect(spy)` functions. Instead they're saying that we should test the end result on the page. But there is no "page" because the modal is being tested in isolation, which I also believe to be a best practice.

Another suggestion was to add a success or failure string to a Mock Service Worker (MSW) response string, like "You've successfully saved the new data". The reason I don't like this approach is because:

1. Such a string is just an artificial construct in the test, so what does it really prove?
2. If there are calculations involved with what is sent by the POST or PATCH, don't we want to know whether the correct data is being sent? For example, if the user was prompted to enter the number of hours they worked each day in the past week, wouldn't we want to compare what was entered into the `input` elements vs. what was sent? And maybe those hours are summed (for some reason) and included in another property that was included - wouldn't we want to confirm that the correct sum was sent?

I do respect the opinions of my colleagues but have yet to hear anything from them that justifies dropping the approach I've employed and adopting one of their alternates. So I'm seeking insight from the community to better understand if this is a practice you would follow ... or not.