Kitab is a handy tool for PHP developers that helps with two things:
There are a number of tools that do the first one (phpDocumentor, Doxygen, Sami, etc). However I don’t remember seeing anything that accomplishes the second task.
GitHub is one of the greatest tools for developers ever. And it keeps getting better. Most of the new features that GitHub introduces are usually generic and apply to all developers universally. Today, however, they have a special present for the PHP developers – Quickly review changed functions in your PHP pull requests. This is mighty useful, especially on the larger pull requests.
Here is a nice review of the top 10 best automation testing tools circa 2018. It covers the following:
If you are just setting up the QA team or department and want to know what’s new and hot, or old and tested in the world of automated testing, have a look at these tools.
I’ve trained more people on the subject of pull requests than I care to remember. But I’ve never came close to explaining the best practices as well as this Slack Engineering blog post does:
Basically, your reviewer is totally missing context, and it is your pull request’s job to give them that context. You have a few options:
- Give it a good title, so people know what they’re getting it into before they start.
- Use the description to tell your reviewer how you ended up with this solution. What did you try that didn’t work? Why is this the right solution?
- Be sure to link to any secondary material that can add more context — a link to the bug tracker or a Slack archive link can really help when describing the issue.
- Ask for specific feedback — if you are worried that the call to the `fooBarFrobber` could be avoided, let them know that so they can focus their effort.
- Finally, you should explain what’s going on for your reviewer. What did you fix? Did you have any trouble fixing the bug? What are some other ways you could’ve fixed this, and why did you decide to fix it this way?
Not every pull request needs every single one of those things, but the more information you give your reviewer, the better they will be able to review your code for you. Plus, if someone ever finds a problem in the future and tracks it down to this pull request, they might understand what you were trying to do when they make a follow-up fix.
Give your reviewer all the context they need to get up to speed with your bug so they can be an informed, useful code reviewer. It’s all about getting your reviewer onto the same page as yourself.
My colleague Andrey Vystavkin has been setting up a testing environment for our CakePHP projects recently.  We had one before, of course, using PHPUnit.  But this time we wanted to add Google Chrome headless browser with some form of JavaScript test suite, so that we could cover functional tests and a bit of front-end.  Andrey described the configuration of NightwatchJS on TravisCI in this blog post.  If you are more of a “show me the code on GitHub” person, have a look at this Pull Request (still work in progress) on our project-template-cakephp project.
Once we are happy with the TravisCI configuration, we’ll be bringing this setup to our BitBucket Pipelines environment as well.
The setup is also based around CakePHP framework, but it’s easy enough to adopt it to any other framework, PHP or not.