PHP is a loosely typed interpreted language. That means we cannot compile our scripts and find possible execution errors without doing explicit inspections of our code. It also means we need to rely on conditional type checking or using phpDoc comments to tell other devs or IDE what kind of value to expect. Really there is no way to assess the quality of the code or discover possible bugs without thorough test coverage and regular review.
DDEV is a local development stack built on top of Docker. It gives you all of your environment needs without messy configured on your host machine, without needing to know Docker or configure your own containers. Which is great, and makes life easier. Instead of just using DDEV to develop your site or application locally, why not also run your tests within it?
Working in object-oriented programming is great. You can define interfaces which specify a contract that implementers need to fulfill. You can then extend these to define your end requirement and provide the implementation. This also means you can guarantee an object that implements that interface will have a guaranteed set of known methods. In Drupal, all entities implement EntityInterface, this is how we know that an entity can return its identifier, label, language, and other common methods.
When it comes to Drupal and external data, I use Migrate. A lot. Like a lot, lot, lot. Many times this data is being imported over CSV files that are pushed to a server at some defined interval. Usually, the data can be derived directly from the CSV file itself, other times a custom process plugin derives data from other information. Drupal's Migrate system has two steps to check if new data should be imported or skipped. First, you can tell the migration source to track changes for each row. Then, if you are tracking changes, it hashes each row of data to see if it has been changed.