Scott Keck-Warren has a quick post to his site sharing a method for keeping data providers maintainable in your unit tests. Data providers are a quick way to retest the same logic with several different types of data and not have an individual test for each.

I’m a big fan of using PHPUnit’s data providers feature because it allows you to easily run a lot of data through the same kinds of tests over and over again without having a bunch of duplicate code sitting around. But they aren’t always the easiest thing to come back to an understand.

He briefly introduces how data providers are used in PHPUnit testing, including a brief code example. The errors that can come up with this common setup can be cryptic to debug. He recommends a slight alteration to the data provider return structure to use an associative array instead of a single-level array. This way, if there's an error the resulting message refers to the index, not just a number making a bit more sense and aids in debugging.

The SitePoint PHP blog has posted a tutorial continuing their look at the features of the Yii2 framework. In this latest post author Arno Slatius covers the use of the GridView and ListView components to render tabular data.

In my previous article about Yii 2.0, I introduced the ActiveRecord implementation. Once you have some data in your database you’ll want to be able to show it. Yii uses DataProviders to interact with data sources and it provides some widgets to output the data. Of these, the ListView and GridView provide the most functionality.

In his example he shows how to render tags about authors, articles and related tags into a simple table with contents provided by a data provider. He talks about the three different types of providers, activedata, sqldata and arraydata, and briefly shows each in use. He shows how to configure the GridView element to use the provider and set up the column data. He also covers the use of the sorting and pagination functionality already built into the tool.

Theo Kouzelis has a recent tutorial posted showing you how to make your PHPUnit tests a bit cleaner with the help of data providers, a built-in tool for PHPUnit that allows for easier validation of larger datasets.

When writing tests I try to describe the test in the function name. I use the format testDoesSomethingWhenPassedSomething to first describe the assertion and then the context. [...] When I have many data sets running against the same test I will use the frameworks data providers to make the code less verbose.

He includes code examples to show both the difference between the single data tests and one using a set of email addresses to validate their correctness. He notes that the error message using data providers can be confusing (and maybe hide the real problem) so he offers a solution to make it more readable: associative arrays. The trick is that PHPUnit uses the key to display the error and by making this unique you can make the error output more informative.

Code duplication is a common problem for developers. It's easy to copy and paste code around your application, but you're asking for trouble. Unfortunately, this kind of problem also extends to unit tests. In this new post to his site James Fuller looks at one way to help with this - using the @dataProvider to limit the repetitive data sets across tests.

PHPUnit offers a handy annotation called @dataProvider which can be used for all sorts of handy testing situations. Typically you will use this to feed in a wide variety of data into the same test to ensure that the system-under-test can handle a variety of inputs. Over time I have discovered a few other neat uses for dataProvider methods that I want to share with you today.

He provides some code samples showing how to use the dataProvider in a few tests, setting up an "allowed word" example. He gets a bit more complex with another test that takes in multiple parameters to "mix colors". In his last example he shows a data provider that converts names from camelCase to user_scores.