While not specific to PHP Jani Hartikainen asks an interesting question in his latest post - how many tests are too many?. He gives an example of the number of tests in a widely used open source project and how, sometimes, more tests doesn't mean better code.

Some time ago I stumbled upon some crazy stuff… Specifically, I found out that SQLite has 787 times more tests than they have actual code! It’s no joke, it’s documented right on their website. While they have about 116 300 lines of source code, they have 91 577 300 lines of test code.

That sounds completely insane. [...] I bet you’ve sometimes wondered what is the right amount of tests to write. In some cases, it’s easy to end up with more tests than code. [...] When thinking of how many tests is enough, we need to think of what the goals are – both for the tests and our actual project.

He focuses in on this last idea, talking more about the SQLite project and its test suite. He then helps answer the main question - how do you know how many tests are enough? Should you "bend over backwards" to make tests for every possible scenario just because you can? He suggests a few things that can help the situation including refactoring where testing is difficult and writing regression tests for bugs fixed.

On the SitePoint PHP blog author Andrew Carter has shared a "quick tip" about using a disposable database in the testing of your Symfony-based applications.

Testing code that interacts with a database can be a massive pain. Some developers mock database abstractions, and thus do not test the actual query. Others create a test database for the development environment, but this can also be a pain when it comes to continuous integration and maintaining the state of this database.

In-memory databases are an alternative to these options. As they exist only in the memory of the application, they are truly disposable and great for testing. Thankfully, these are very easy to set up with Symfony applications that use Doctrine.

He talks first about the built-in functionality Symfony has to use different configuration files for different environments. This allows for easier testing in a more isolated setup than replicating development. He then shows how to use Doctrine with a SQLite in-memory database with a simple update to the config_test YAML configuration file. He also includes the code for a DatabasePrimer class that gets the Doctrine entity manager and executes the the schema tool to set up the schema in the database and "prime" it with any fixtures you might need.

The Scotch.io site has a tutorial they've posted showing how to prototype a site quickly using Laravel and its built-in server/SQLite support.

If you are a seasoned Laravel developer, you know the usual project setup drill that involves creating a new project, a fresh database, and adding a virtual host entry to Apache.

If you are starting from scratch, the Apache and MySQL installation can take some time and slow things down for you. However, I will show you how you can jump start your Laravel development without Apache and MySQL.

The tutorial shows you how to use the internal PHP server to host the application, run a Laravel site inside it and integrate SQLite as the database. Each section comes with some example code and the commands/configuration you'll need to make the system work. They also take a "deep dive" into Larvel's serve command and how it bootstraps the Laravel instance for the PHP built-in server. The post ends with a look at switching back to MySQL and a comparison of SQLite vs MySQL (as well as using SQLite for production).

In a new tutorial Dalibor Karlović shows you how to test your Symfony application in production to get a more "real world" picture of how your application is performing for the rest of the world.

The problem here is that you almost cannot guarantee that you can replicate the production environment down to a single detail, it might have a slightly different underlying system, a slightly different network setup, even a different updates applied might mean it works for you, but not on production.

He starts the post by talking about the testing support already built into Symfony and the different parts tested by unit versus functional tests. He gets into some actual (functional) test examples, showing how to evaluate the response from an API request and where the major part of the overhead is - the database interaction. He takes the next step and looks at how to avoid "impure" functional testing and only then starts talking about switching between database types (SQLite vs MySQL) for better performance measurements. Finally, he gets to the topic of the article, running tests in production, and includes a "gotcha" to look out for (hint: don't hard-code IDs).

On the AndroidHive site there's a recent tutorial (plus screencast) about combining PHP, MySQL and SQLite to act as the backend authorization for your Android application.

In my previous article Android Login and Registration Screen Design i explained designing the login and registration interfaces, but it has no functionality. In this tutorial i am explaining how to build complete login and registration system in android using PHP, MySQL and SQLite. Also this tutorial covers how to build simple API using PHP and MySQL.

The tutorial walks you through each step of the process:

• Creating MySQL Database and Tables
• Building PHP API Classes
• Starting Android Project
• Making the JSON Parser, SQLite Database Handler and User Functions Classes
• Designing the Screens
• Switching between Activities
• Finally Updating AndroidManifest.xml

If you want to get started quickly, you can just download the final result and go.

On the php|architect site there's a recent tutorial from Jeremy Kendall about full-text searching in SQLite, a lightweight database alternative that, since it's stored locally, can be used without a full database server.

Full-text search with SQLite is so ridiculously easy to implement, there are only two valid reasons you haven’t done it yet. The first is you don’t need the full-text capability, and the second is you didn’t know it could be done.

In his method he creates a full-text search table (using fts4) and populating it with your data. You can use the "MATCH" keyword in your SQL to find the closest matches and even handy modifiers like "NEARBY", wildcards and token/prefixes in queries. For more detailed information, check out the SQLite documentation for a full guide.

If you're in the process of prototyping a site or just need a lightweight storage tool for your application, you might look into SQLite. Fortunately, PHP has direct support for it and this great tutorial from ZetCode.com will introduce you to some of the basic concepts you'll need to get working (it's a bit older, but still very useful).

This is a PHP programming tutorial for the SQLite database. It covers the basics of SQLite programming with PHP language. There are two ways to code PHP scripts with SQLite library. We can use procedural functions or OOP objects and methods. In this tutorial, we use the classical procedural style. You might also want to check the PHP tutorial or SQLite tutorial on ZetCode.

They go through the basic installation (on a linux platform, but easily adapted to others) including changes to your php.ini and the creation and use of a first sample database. You'll find the interface very similar to some of its other RDBMS cousins with a few exceptions. They show you the CRUD basics - creating records, reading the contents of a table, updating data already there and deleting records. There's also a simple form tutorial that takes a name and gender and does the inserts.

New on PHPBuilder.com there's a tutorial from Leidago Noabeb about using the PDO functionality that comes installed on many PHP platforms out there to access just about any database you might need to work work. This includes technology like MySQL, DB2, SQLite and PostgreSQL.

PHP Data Objects, or "PDO" as it is commonly known, is a lightweight database abstraction layer that is arguably the best, at least in terms of speed. A great deal of this speed is owing to the fact that the PDO extension was compiled with C/C++. The extension became available in PHP5, and as with any other database abstraction layer, its aim is to provide a uniform interface to access a variety of databases. This is also a way for developers to create portable code for a variety of platforms.

The tutorial shows you how to find the enabled PDO connection types for your installation (and where to go if you have access to turn more on or off). They show an example connection - in this case, to a MySQL database - and how to run a query or two using this new resource.

Johannes Schluter has a quick new post to his blog today talking about parts of the sqllite extension that will be dropped from the core - the current sqlite_* methods and the pdo_sqlite driver.

The issue there is that this depends on the SQLite 2 library which isn't supported by upstream anymore for a few years. It was a logical step therefore to remove this extension from PHP trunk. The support for the sqlite3 extension and the PDO_sqlite driver (same link as above, read it carefully), which use version 3 of the library, are continued.

The change probably won't be happening in any of the PHP 5.3.x releases but should becoming in PHP 5.4 so, as he advises, you might need to rebuild your database file and change your application to correct things for the changes.

On NETTUTS.com today there's an intermediate tutorial showing you how to create a simple polling system for your site - complete with a database backend and a CSS styled results view.

Polls are nearly ubiquitous on the web today, and there are plenty of services that will provide a drop-in poll for you. But what if you want to write one yourself? This tutorial will take you through the steps to create a simple PHP-based poll, including database setup, vote processing, and displaying the poll.

They include all of the code and markup you'll need ready for cut & paste - the SQL for the database backend (they chose SQLite), the HTML for the question and answer sides and the CSS to style them both. No javascript is needed to make the example work. There's even some process flows to help you understand the paths the application can take.