When you're just getting started with automating your JavaScript testing, there's a lot of questions. You'll probably see people talk about unit testing, TDD or Test-Driven Development, and BDD or Behavior-Driven Development. But which one of them is the best approach? Can you use all of them? I've talked to a number of JavaScript developers, and there seems to be some confusion about all this. So, let's take a look at Unit testing, TDD and BDD, and fix some of the common misconceptions about them out there.

For each he provides an overview of this basic concepts and a bit of sample code showing it in action. For TDD (test-driven development) there's not really a way to show it specifically in code as it's more of a practice. Instead he gives a "checklist" to follow when practicing it.

Unit Testing gives you the what. Test-Driven Development gives you the when. Behavior Driven-Development gives you the how. Although you can use each individually, you should combine them for best results as they complement each other very nicely.

Blackfire Profiler by SensioLabs automatically gathers data about your code's execution, such as RAM, CPU time, and disk I/O. Homestead makes it a breeze to use this profiler for your own applications. All of the proper packages have already been installed on your Homestead box, you simply need to set a Blackfire ID and token in your Homestead.yaml file

With the configuration set up, the only installation the user needs to make is setting up the companion extension (Chrome) for your browser.

In the latest post to the AWS PHP Development blog Jeremy Lindblom looks at a new feature of their PHP SDK that allows for more flexibility (and easier handling) when using DynamoDB for document storage in storing more complex data.

Back in October of 2014, Amazon DynamoDB added support for new data types, including the map (M) and list (L) types. These new types, along with some API updates, make it possible to store more complex, multilevel data, and use DynamoDB for document storage.

He talks about a new class thats been added to help work with the DynamoDB storage, the DynamoDb Marshaler (in version >= 2.2.7) that handles the push and pull of the JSON document data directly from the storage, reducing the need to perform the operation manually. He includes code examples of its use and JSON examples of what results are returned on a get request. He also shows how to use it with a native PHP array, translating it with help from the Marshaler and the "marshalItem" method.

In the latest show from the Three Devs & A Maybe podcast hosts Michael Budd, Fraser Hart, Lewis Cains and Edd Mann talk about a wide range of topics with a focus on the SOLID development principles.

This week we have a three developer podcast with discussion on a host of topics. We kick off with how Fraser has enjoyed building his first bonus slot game, written entirely in JavaScript and HTML5. Preprocessors are a huge part of the JavaScript ecosystem at this time, with so many to choose from we discuss a couple of the more popular ones. This leads on to Photoshop discussion, ReactJS, the cool features present in ES6 and how you can use them today with transpilers. Following this we move on to the SOLID principles, the overuse of inheritance, technical debt and the concept of Over-DRY vs. Software Value. This then takes us on to a strange 'rubber duck' example Edd conjured up to help try and explain the Liskov substitution and Interface segregation principles. Finally, we discuss Edd's media server setup and how he has got it to a staged that he is finally happy with it.

The SitePoint PHP blog continues their "How to Build Your Own PHP Package" series with their latest post (part two of the series) covering the use of test-driven development while working on the package code.

In part 1, we set up our development environment, baked in some rules as inherited from The League, and created two sample but useless classes - Diffbot and DiffbotException. In this part, we'll get started with Test Driven Development.

He starts by briefly introducing PHPUnit, a PHP-based unit testing tool, and how to use it to generate the HTML version of the code coverage report. He helps you define a good phpunit.xml configuration file and how to execute a first sample test (code provided) from inside PHPStorm. From there he adds one some more complex testing of exception handling and checking the class types. With this foundation, he moves into the test-driven development (TDD) practices. TDD means writing the tests before writing the code to make those tests pass. He gives an example of this and shows how test abstract classes too. He then comes back around and writes the code to satisfy the test.

The JetBrains blog has posted about an update to their popular PHPStorm IDE tool. In this new post they talk about the next level of integration they've introduced for those developing Laravel-based applications.

They walk you through each of these two new updates, showing what kind of features they enable and some screenshots of the interface in use. For more information and to check out other features in this new plugin/helper setup, see this documentation page.

When I first started writing this post, I considered giving it a title such as "How to set up local PHP development with dynamically configured mass virtual hosting on Apache 2.4″, "Quick and easy prototyping using Liip PHP, Dnsmasq or Proxy Auto Configuration" or even "The Ultimate Guide to Rapid Development on OSX 10.10″. I did not.

In my daily job as a Development Manager, I don't get to code very much, but when I do, I want to have a setup that allows me to quickly create development projects and prototypes in the ~/Sites folder and have them show up as vhosts automagically, without having to edit any configuration file(s).

His three steps do require a few prerequisites including Homebrew, but that's easy enough to set up. Here's his process:

Step 1 - installing (my preferred version of) PHP

Step 2 - enable hosting under ~/Sites

Step 3 - add a local DNS server

He also includes a "Step 3a" that shows how to test the installation via a simple response from each of the domains.

On the AirPair site today they've posted an article from developer Brian Fenton covering several things he sees as the best practices for modern PHP development, a listing of several tool, practices and suggestions to improve your skills as a PHP developer and bring them to the next level.

He breaks it down into five main sections (each with their own subsections):

Setup and configuration

Use Composer

Follow good design principles

Object calisthenics

Unit testing

Some of the points made under each of these sections include suggestions about using sensible defaults, installing and using Composer, the SOLID design principles and unit testing tools. Check out the full post for more great suggestions and techniques to improve your skills.

On the SitePoint PHP blog there's a new tutorial showing you how to get started with Vagrant and PHP to create easier, more flexible development environments via virtual machines.

Vagrant is a tool for creating and managing virtual environments that help many developers not have to care about the "works on my machine…" problem. Vagrant creates reusable development systems that can be used again and again, helping you keep your system clean of too many installations.

They offer "five easy ways" to get started including various tools and services:

The SitePoint PHP blog has a new post today sharing what they (well the author, George Fekete) see as the top 18 critical oversights common to web development in recent years. While the examples are in PHP, the principles could apply across multiple other languages.

Over the past years I had the opportunity to work on some interesting projects, complex in nature with an ongoing development, constantly upgrading, refactoring and adding new features to them. This article will cover the biggest coding oversights most PHP developers make, when dealing with medium and large projects. Oversights such as not differentiating between development environments or not implementing caching and backup. [...] The root of these problems lies mainly in developers' knowledge and experience, especially the lack of it.

He's broken them up into three different overall types: design, application and database levels. Included in his list are things like:

Developing with error reporting off

Not implementing caching

Not using automated tests

Not differentiating between read / write queries

Not using transactions

No backup

No monitoring

Check out the full post for the rest of the items on the list, all including examples and explanations.