Test a script reading from external source

You need a multi-layered approach. Which specific techniques you draw on depend on the amount of time and effort you're willing to invest in making sure your scripts behave appropriately and are robust to errors.

During development, be defensive when receiving input. Try to gracefully recover from as many bad input cases as possible. For example, if you expect JSON, validate that you get JSON responses. If you expect input data to have a certain data type, range limits, or structure, validate that it is the right type or within the expected limits. Design observability into the system so when one of these defenses is triggered, you have insight into the messages that triggered it for debugging. You can use observability to design unit (and, where possible, integration) tests to monitor the behavior and prevent regressions.

At a unit testing level, I'd focus on testing against the contract along with your script's defensive techniques. Using sample data, mocking the server and feeding controlled test data into your application. In some cases, you may be able to capture and use real-world data as test data, but you may still need to craft additional test data based on documentation. You may also have to create specific data that falls outside of expected inputs to cover your defensive checks. Note that unit testing is about testing your application, so you don't need to be concerned with cases where the server does not behave as documented. These would be found in integration tests (or, if you can't run integration tests, production).

Integration tests, if possible, can be run against a test server. Try to stand up a test instance of the server or, if it's a vendor-run server, try to get access to a test or sandbox instance. This may have costs, so it's not always feasible. Especially when considering vendors, the capability to stand up or access test servers is something to ask about.