Info about Ryan

https://www.linkedin.com/in/ryanwelcher/

Preface about the conversation

I thought it would be a good idea to do some research into companies that are similar to us that have likely solved the problems we will be facing as we try to integrate testing into our development process. The company I came across that I thought would be great to have a discussion with was 10up. Conveniently, 10up is also a 100% distributed company which means they could provide some helpful insights as we onboard our first intern remotely.

I asked Tom if he knew anyone at 10up, which it turns out he knows a few, but we decided that Ryan would be one of the best to talk with since he is more local and he works primarily on WordPress projects.

Testing

What is the process of getting a client on board with creating tests for a project?

Let’s start with the fact that it is very difficult to get a client to agree to include testing in the project’s budget for both new and ongoing projects. Although trying to perform testing without the client’s support is hard, testing can sometimes save a project. Ryan provided the example of a project he worked on where he was inheriting a messy legacy codebase. He told me that making even the smallest of changes was proving to be increasingly complex since the project’s current state was so volatile. He also said that without testing, this project would have failed.

He outlined some of the basic internal requirements they implemented around testing:

• Write tests as you write code.
• Automate as much as you can.
• Test for every bug (CSS related bugs not included).
• If the project is really volatile, no code can be pushed without at least some basic tests being written first.
• Model your testing around the component level of your code.

Changing the client’s mentality around testing

There are a few ways to explain testing to a client that will help them understand the importance it has in their project’s success.

• Testing isn’t meant to fix problems, it’s meant to prevent problems from reoccurring and to prevent future problems.
• We are writing tests so that we don’t introduce new bugs. It will be a lot easier to solve bugs if you don’t have to worry about any new ones potentially being created.

At the end of the day though there are some projects that will not benefit from testing. Those projects are ones that have extremely limited timelines, where most of the PHP code just lives in the functions.php file, and you are working only on a section of the code and handing it off where will potentially never be seen again (think Solv).

How can we best prepare for including testing in the budget?

Maintenance projects, where the client has us on a retainer, are usually the best for including testing into the budget. This is because if there is any remaining time it can be spent on building and running tests. Also if you were unable to build the necessary tests the previous month you can always build them next month.

Another bit of advice Ryan offered was to pad our estimates to at least include the basic level of testing which we will discuss further down.

Implementing testing in the dev department

Since we don’t currently have a good testing practice at Art & Science I thought it would be a good idea to ask Ryan about what it was like adopting a testing practice internally. He told me that while no one will ever say “no” to testing, there is a learning curve that has to be understood.

This is where automating as much of the testing process as possible can be beneficial. If we can create at the very least an automated testing suite using tools such as PHP-CS-Fixer, Visual Regression Testing, and Git Hooks then we will see a significant improvement in the quality of code created. We will also see customers coming back happy to work with us again since their product works seamlessly and the only maintenance we are performing is new feature additions.

Testing Tools

• PHPUnit – It’s uncommon that we will have to write anything but Unit tests for a WordPress project. Luckily there is a handy library called PHPUnit that can easily be included. You may have used it in Laravel before or if you haven’t I am planning on preparing a dev lunch and learn around PHPUnit.
• PHP CS Fixer – PHP Coding Standards Fixer is a tool that fixes your code to follow standards; whether you want to follow PHP coding standards as defined in the PSR-1, PSR-2, etc., or other community-driven ones like the Symfony one. You can also define your (team’s) style through configuration.
• Visual Regression Testing – Visual Regression Testing ensures code changes don’t have unforeseen repercussions. This provides a helpful visual aid to check against CSS changes, plugin updates, and third-party script updates.
  • BackstopJS – A tool used to run visual regression tests that compares known reference states against updates.
• Git Hooks – Git hooks are scripts that Git executes before or after events such as commit, push, and receive. They are a built-in feature – no need to download anything. They are run locally. These hook scripts are only limited by a developer’s imagination.
  • Husky – an npm package that can prevent bad git commit, git push and more. It can be used to lint JavaScript and CSS files and prevent any code from being pushed if it doesn’t meet a certain standard.
• WP Acceptance – There are many acceptance tests frameworks out there. They all have one major flaw – everyone executing the acceptance tests must be running the exact same code on the exact same database and environment to guarantee the same results. Ensuring a team of developers (and a CI pipeline) are all using the same database in the same environment has been nearly impossible until now. WP Acceptance is unique in that it allows you to run your acceptance tests against a codebase in defined and shareable environments. 
• ESLint – A pluggable and configurable linter tool for identifying and reporting on patterns in JavaScript. Maintain your code quality with ease.

It’s important to note that it is much easier to integrate these tools into a new project than it is to integrate into an existing codebase. But sometimes adding these tools to an existing codebase is necessary for the project’s survival.

Onboarding Remotely

10up has created a well-defined, step-by-step process to onboarding someone. When someone joins the team they are given a big checklist with all the things they need to read, sign-up for, and anything else.

Ryan provided some key thoughts on what can make this person’s onboarding as best as it can be:

• Be very available.
  • They will likely have a lot of questions and in a remote environment, they can’t just turn to someone and ask their question. This means that I will need to find a way so that they can almost have an always direct communication line to me. When I am not available I need to let someone else know so that the intern can go to them instead. The worst thing we can do is not be available and be the “blocker” for the intern to continue to learn.
• When they do something well, make sure they know it and that the whole team knows it.
  • Since we are onboarding an intern there is a likely chance that they may feel some imposter syndrome from time to time. They are new to development and don’t have the rigid guidelines of school or a boot camp anymore to determine their success. This is completely normal, but we can help them out by letting them know when they have done something well and we can take it a step further by letting the team know as well. Not only will this give them a feeling of self-confidence but it will provide helpful insights to the team and the rest of the company as to where this person’s progress is.
• Have a general order of what learnings need to occur and where they can find the necessary information.
  • It’s important to make what you can of their learning be independent, while still keeping yourself available for questions. This will provide them with a sense of ownership over their learning which is beneficial to stymying their potential feels of imposter syndrome.
• Read through your own documentation.
  • It’s embarrassing and confusing if documentation A says to do one thing and documentation B says to do another. Clean up old, unnecessary documentation and ensure there is no conflicting information.
• Things will change. Embrace it. Iterate on the process.
  • One big takeaway Ryan had about 10up’s onboarding process is that it is very different today from when he was hired five years ago. Always be improving.