The following are some generic rules that are valid for any unit test and not just PHPUnit:

Independent: Each test needs to run independently from other tests
and environments.

Fast: To have useful tests and be able to run them as often as possible
(for example, as pre- or post-commit hooks), tests need to be fast.

Repeatable: You should be able to run a test as many times as you want with the same result.

Up to date: Tests are written once, but code can be changed or extended. If you are not going to keep tests up to date, the initial investment in tests will be just a waste of time and money. The rule is, whoever breaks the test, fixes the test.

Short: Tests should be just a few lines—easy to read and understand.

Resilient: Once written, tests shouldn’t change till the behavior of tested
class/method changes.

PHPUnit Essentials – by Zdenek Machek

“How I Explained REST to My Wife” REST part 1

Wife: Who is “Roy Fielding”?

Ryan: Some guy. He’s smart.

Wife: Oh? What did he do?

Ryan: He helped write the first web servers and then did a ton of research explaining why the web works the way it does. His name is on the specification for the protocol that is used to get pages from servers to your browser. Continue reading “How I Explained REST to My Wife” REST part 1

Let’s Make The Code World A Better Place – #2

The Primal Conundrum

Programmers face a conundrum of basic values. All developers with more than a few years experience know that previous messes slow them down. And yet all developers feel the pressure to make messes in order to meet deadlines. In short, they don’t take the time to go fast! True professionals know that the second part of the conundrum is wrong. You will not make the deadline by making the mess. Indeed, the mess will slow you down instantly, and will force you to miss the deadline. The only way to make the deadline—the only way to go fast—is to keep the code as clean as possible at all times.

Clean Code

Let’s Make The Code World A Better Place – #1

It’s not enough to write the code well. The code has to be kept clean over time. We’ve all seen code rot and degrade as time passes. So we must take an active role in preventing this degradation.
The Boy Scouts of America have a simple rule that we can apply to our profession. “Leave the campground cleaner than you found it”.
If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot. The cleanup doesn’t have to be something big. Change one variable name for the better, break up one function that’s a little too large, eliminate one small bit of
duplication, clean up one composite if statement.

Clean Code