Writing Unit Tests with PHPUnit, Part 3: XML Configuration

In the past posts in this series, I’ve covered the following two topics:

  1. Writing Unit Tests with PHPUnit, Part 1: The Set-Up. A guide to getting started with writing PHPUnit tests through the use of a basic cache and using the setUp method of the framework.
  2. Writing Unit Tests with PHPUnit, Part 2: The Tear Down. A tutorial on how to write unit tests that properly leverage the setUp and tearDown methods of PHPUnit.

Each of the above is meant to provide a primer for how to get started with writing very basic unit tests. Things can get more complex especially as an application or project grows (but that’s always true, right?).

But to make sure one is prepared for that, there’s one final component to unit testing that I believe we should focus on and that’s understanding the PHPUnit XML Configuration File (which you may have seen in other projects as phpunit.xml).

Read More

Writing Unit Tests with PHPUnit, Part 2: The Tear Down

Late last month, I started talking about writing unit tests in PHPUnit for WordPress-based code. This primarily included the idea of setting up PHPUnit, the setUp function, and writing basic tests.

This did not, however, discuss what I know about the tearDown function which is still an important feature of writing using tests. Further, there’s also two ways to consider writing tests for WordPress projects.

Namely:

  1. writing tests specifically for plugins and application-layer functionality,
  2. running unit tests against the WordPress application.

Before moving forward with this particular post, though, I recommend catching up on what I’ve covered thus far. This includes the following posts:

  1. A WordPress Development Environment (Using a Package Manager)
  2. An IDE for WordPress Development
  3. Working with User Settings in Visual Studio Code
  4. Writing Unit Tests with PHPUnit, Part 1: The Set Up

Once you’ve done that, return to this post and let’s continue discussing the tearDown function and what unit tests in the context of WordPress actually look like.

Read More

Writing Unit Tests with PHPUnit, Part 1: The Set Up

Earlier this month, we began looking at installing PHPUnit in Visual Studio Code with the ultimate goal of learning how to write unit tests for our WordPress-based projects.

To that end, this post assumes that you’ve read the following posts and it assumes that you’ve caught up with a handful of previous posts:

  1. A WordPress Development Environment (Using a Package Manager)
  2. An IDE for WordPress Development
  3. Working with User Settings in Visual Studio Code

And, of course, installing PHPUnit in Visual Studio Code as linked above. Once that’s done, we’ll be ready to proceed. But one thing to keep in mind is that this will night be a traditional or a comprehensive course in writing unit tests.

Intalling PHPUnit in Visual Studio Code: Installing the PHPUnit Extension

Instead, it’s all about writing unit tests for WordPress projects.

Read More

Abstract Classes, Part 2 – Abstract Classes and Interfaces

In the previous post in this series, I walked through:

  • the basics of abstract classes,
  • how to implement them,
  • and provided working code examples.

And though I think understanding abstract classes are key in laying a strong foundation for object-oriented programming, I often see that it can be confusing when it comes to comparing them to interfaces and knowing when to use them.

Abstract Classes and Interfaces

 

Read More

Abstract Classes, Part 1 – Abstracting Behavior

About a month ago, I wrote about one of the pillars of object-oriented programming (specifically being Abstraction). In the post, I defined abstraction as the following:

Instead, we’re going to be abstracting ideas into their classes. And there’s a key idea here: A class should represent a noun.

And though that’s still true, the idea of abstract classes is something that’s different in object-oriented programming.

It sounds confusing, right? That is:

  • on one level, we have abstraction being defined as the idea that we take an idea and represent it in a class,
  • on another level, we have abstract classes which are used to help define functions that subclasses must implement.

And if that isn’t confusing enough, we mix this in with interfaces which provide a contract implementing classes must follow, and then we mix it with abstract classes which define methods that also must be implemented but can also implement methods of their own.

Confused yet? No worries. The whole point of the next three posts is to do the following:

  1. Define what abstract classes are,
  2. Describe the different in abstract classes and interfaces,
  3. Help decide when you want to use one over the other.

With that said, here’s the whole idea behind abstract classes.

Read More