Programmers: TDD your Legacy Code to Single Respnsibility Principle. Part 3 – Dependency Injection For the New Class and Wrap Up

TL;DR

This article series shows the importance of having unit tests. It also shows the importance of adhering to the Single Responsibility Principle (SRP), as we get a new requirement for our code base. We take a section of “legacy code” and refactor it to more closely follow SRP, all while maintaining the safety net of unit tests and leveraging Test Driven Development (TDD). We also cover using Dependency Injection in this TDD context.

This was originally going to be one post, but ended up WAY too long, so it will be a series of three posts:
Part 1 – Setup and Planning the Responsibility Transfer
Part 2 – The Glorious TDD Cycle
Part 3 – Dependency Injection For the New Class and Wrap Up

Please following along on GitHub. The name of the downloaded .zip file for various links in this article correspond to commits in this Github repo.

In part 2 of the series, we finished the QuestionAndAnswerValidator class, and its unit tests. In this part, we’ll use Dependency Injection to make the GuessForm class aware of the new QuestionAndAnswerValidator class, as well as use TDD when modifying the GuessForm::validateForm method to utilize QuestionAndAnswerValidator.

Making the Form Aware Of New Validator Class – Dependency Injection

Now that we have the answer validation logic extracted to a new class, and that the new class is covered with unit tests, we can go to work removing that logic from the GuessForm class. To keep the tests passing at all times, we first need to provide and utilize a QuestionAndAnswerValidator object in the GuessForm class. For this, we’ll leverage the dependency injection (DI) container that the Symphony framework provides within Drupal 8.

Continue reading “Programmers: TDD your Legacy Code to Single Respnsibility Principle. Part 3 – Dependency Injection For the New Class and Wrap Up”

Programmers: TDD your Legacy Code to Single Respnsibility Principle. Part 2 – The Glorious TDD Cycle

TL;DR

This article series shows the importance of having unit tests. It also shows the importance of adhering to the Single Responsibility Principle (SRP), as we get a new requirement for our code base. We take a section of “legacy code” and refactor it to more closely follow SRP, all while maintaining the safety net of unit tests and leveraging Test Driven Development (TDD). We also cover using Dependency Injection in this TDD context.

This was originally going to be one post, but ended up WAY too long, so it will be a series of three posts:
Part 1 – Setup and Planning the Responsibility Transfer
Part 2 – The Glorious TDD Cycle
Part 3 – Dependency Injection For the New Class and Wrap Up

Please following along on GitHub. The name of the downloaded .zip file for various links in this article correspond to commits in this Github repo.

In part 1, we planned the responsibilities we would transfer from GuessForm to the new QuestionAndAnswerValidator class, and did some other setup. Now we will start the TDD cycle to implement the new responsibilities on our new class all while maintaining unit test safety.

Test Driven Development (TDD) For The New Class We Will Extract – Happy Case

TDD is another concept discussed in Robert C. Martin’s Clean Code. In the discussion, he poses a method of writing production code, whereby you write a unit test that fails, and then you write the production code until the test passes. Though, don’t think you have to write every single test before you write any production code. Contrarily, we’ll basically keep the unit tests one small step ahead of the production code, and develop both at the same time. By doing this cycle of writing a test, production-coding until the test passes, and then repeating, we constantly keep the code in an unbroken state.

Continue reading “Programmers: TDD your Legacy Code to Single Respnsibility Principle. Part 2 – The Glorious TDD Cycle”

Programmers: TDD your Legacy Code to Single Respnsibility Principle. Part 1 – Setup and Planning

TL;DR

This article series shows the importance of having unit tests. It also shows the importance of adhering to the Single Responsibility Principle (SRP), as we get a new requirement for our code base. We take a section of “legacy code” and refactor it to more closely follow SRP, all while maintaining the safety net of unit tests and leveraging Test Driven Development (TDD). We also cover using Dependency Injection in this TDD context.

This was originally going to be one post, but ended up WAY too long, so it will be a series of three posts:
Part 1 – Setup and Planning the Responsibility Transfer
Part 2 – The Glorious TDD Cycle
Part 3 – Dependency Injection For the New Class and Wrap Up

At various points in the article series, I link to .zip files on Github that correspond to commits at stages along our refactoring progression. To find the exact commit on the GitHub repo, just take the name of the .zip file and find the commit id on this page.

Introduction

In the previous article, we demonstrated how to cover an existing method, specifically the validateForm method of a Drupal 8 form implementation, with unit tests. In this article series, we’ll look at how we can leverage the fact that we have unit tests in place, and extract a class from the form implementation in order to more closely follow the Single Responsibility Principle (SRP). We’ll pretend that we get a new requirement for the app, and the logic we extract from the existing validateForm method has functionality that will be needed for this new requirement.

Continue reading “Programmers: TDD your Legacy Code to Single Respnsibility Principle. Part 1 – Setup and Planning”

Programmers: Unit Testing Drupal 8 Form Validation with PHPUnit

TL;DR

In this post, we’ll cover some things I’ve picked up recently using PHPUnit, specifically working with test doubles and mocking methods, in order to unit test a Drupal form validation method. You should be able to easily adapt this code to test your own form validations too. I also stress the importance of having unit tests before refactoring a “legacy system,” as well as make the recommendation for reading Working Effectively With Legacy Code by Michael Feathers.

The Code

The sample code that accompanies this article is located here on GitHub, and the article assumes you have Drupal 8 running on PHP 7. You can download and install the module. It creates a simple form, located at the relative url “/form_validation_unit_test_module.” It is simply a select list where you pick a question to guess, followed by a text box where you enter a guess to the selected question, and lastly a submit button that validates the answer when clicked. The project also includes the unit tests.

Continue reading “Programmers: Unit Testing Drupal 8 Form Validation with PHPUnit”

Pilots and Programmers: Humble Pie (What I’ve Realized in Publishing My First Article)

Getting over fear and pride

Though the idea had kind of always attracted me to do so, I had put off writing anything online for quite a long time because of fear, coupled with my somewhat innate introversion. This was essentially fear of what people would think about me or about what I wrote, and it kept me on the fence. I find it easier to accept criticism from someone I know and trust. Though, when you publish an article or post online, it’s obviously not only the people you know who can read and critique it.

Continue reading “Pilots and Programmers: Humble Pie (What I’ve Realized in Publishing My First Article)”

Programmers: Simple Use Case for Leveraging Visual Studio Solution Configurations

Note: This article was originally published on CodeProject back in April. It underwent several iterations (with the help of one of the community members there), and here is the final product…

Recently I needed to modify a solution that contained a Windows service. This service utilized a DLL that was created from a class library project in an entirely separate solution. I wanted to be able to automatically provide the environment configuration to the class library based on the solution configuration of the client application (service in my case, but a console app in this article), as the class library needed to communicate with different instances of a database and web service based on the environment. This article will walk through a use case that has the following points:

1. We will have a class library that will communicate with a database and web service. To allow the database connection and web service url to be defined by the client, we will create an interface that clients of the class library may optionally implemented to provide said database connection and web service url.

2. We will use the Project Settings of the class library, which will create an app.config file in the class library. This will be the structure that the client solution will need to mimic in its app.config file as well.

3. The client will define two app.config files, one for Release and one for Debug. We will also edit the .csproj file to automatically utilize the correct app.config file based on the solution configuration (whether the client is run in Debug or Release).

4. The class library will contain a default implementation of the interface mentioned in point 1. If the client does not create a class that implements the interface, then the default implementation of the interface in the class library will pick up the database/web service settings, so long as the client follows the correct format in it’s app.config file(s).
Continue reading “Programmers: Simple Use Case for Leveraging Visual Studio Solution Configurations”

Greetings! I’m the PilotProgrammer!

Greetings! I’m Garrett Granacher, the PilotProgrammer. I pilot airplanes and program computers!

This is a new blog that I’m getting started. With it I will share my adventures with both airplanes and computers. If I post a topic on aviation, it will be prefixed with “Pilots”; if the topic is on technology, it will be prefixed with “Programmers”; and should the topic be applicable to both, well, I’ll preface the title with “Pilots and Programmers”!

The Pilot in me enjoys teaching flight lessons, and the Programmer is particularly passionate about software architecture, software craftsmanship, and Test Driven Development. While I do have my favorite programming languages, I’m learning that all languages have their respective strengths, and that the most important thing is to strive for “clean code” that is readable and maintainable, regardless of the programming language.

 

My Background

For the first part of my career, I was a full-time airplane pilot. I started as a Certified Flight Instructor (CFI) and worked up to piloting turbine corporate/charter aircraft with an Airline Transport Pilot (ATP) certificate.

Flying a jet for a career afforded me significant down time in a hotel while waiting for passengers. With this down time, I began to experiment with technology. First I started building automation into spreadsheets for the flight department’s company iPads, as well as writing Excel VBA macros to automate dispatch office tasks. Eventually, I picked up a Mac, self-learned Objective-C, and wrote an aviation iOS app, Fuel Flite.

Now the roles are reversed. I am blessed to now be working full-time as a software developer, but I also keep my CFI certificate current and actively teach flight lessons.

In the 2 years since I started full-time software development, I’ve been lucky to work with a wide range of interesting technologies. Most of my database experience is in SQL Server, though I have also worked with Oracle and MySQL databases. I mostly use C# and PHP for languages, and I have also build web applications using Drupal. I’ve taken a few online courses via Coursera that have exposed me to Java and Python.

When I’m not at the controls of a computer building software, or at the controls of an airplane keeping the dirty side down, you’ll find me on a walk with my wife and daughter or playing the trumpet.