When an unsupported situation (e.g. illegal value) arises in a scientific model, the usual implementation is to stop the model. In more sophisticated cases, some possibly-useful message about why the model stopped is generated. However, the logic for handling these rare cases is often buggy - precisely because the situation in rarely encountered! At any rate, this report-and-abort approach is problematic for TDD because a test which encounters the unsupported situation fails to complete, as opposed to returning with an error condition. (Note: frameworks in languages such as python and java can exit gracefully from these types of situations, but Fortran has no true exception handing mechanism.)
But there is another path.
If instead of halting the execution, the routine in question were to "throw" an exception, the framework would be back-in-business. Even though Fortran does not support true exceptions, the various Fortran unit testing frameworks (and pFUnit in particular) provide means to throw pseudo-exceptions that can then be handled at some other level in the software. (For the curious, the bit of exception handling that is missing is the ability to pop back up multiple levels of the procedure stack.)
So how do we drive this approach with TDD? Simple. We write a test which intentionally creates the "unsupported" condition, and then checks that the desired exception is thrown. "Unsupported" is in quotes, because technically we are now supporting it, albeit in a limited fashion. In order to pass this test, the implementation must throw the desired exception, but only under the appropriate circumstances. (Otherwise the other more-typical tests would then signal failure due to the unexpected exception.)
The frustrating downside of this approach is that the source code (as opposed to the test code) must now link to the testing framework. One can use CPP, to minimize the impact on the other developers, but CPP is its own evil.