MidCamp, the Midwest Drupal Camp, is coming around the corner! March 20th through the 23rd, hundreds of Drupalistas will converge in Chicago for training workshops, contribution sprints, and sessions! This is one of my favorite conferences. The organizers put together so much thought and effort into each detail.

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.

2018 was a weird year. It felt like it just zoomed by and nothing eventful happened. In fact, I feel like most people I have talked to this year felt the same exact way. But, then I sat down to my end of year write up and realized that this year was way more packed than I thought.

This is the third, and final post in my series on running Drupal’s various test suites using the DDEV local development stack.

This is part two of a series on running Drupal’s testing suites on DDEV. We left off last time with trying to execute a FunctionalJavscript test and having every test case skipped because no browser emulator was available.

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.

When I work, I try to follow the principles of Test-Driven Development. I have found it to aid me in writing cleaner code, identifying odd coupling of components or crazy accidental dependencies between components. It also lets me write my API first by using mocks against interfaces I have defined. PhpStorm's auto-test functionality speeds up my test-driven development process.

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.

I moved over to DDEV for my local development stack back in February. One of my favorite things is the ease of using Xdebug.