# phpunit-selenium and the older way of driving a browser from PHPUnit > phpunit-selenium gives PHPUnit a Selenium2TestCase class so end-to-end tests can run against a Selenium 2 server, and its support matrix is organised around PHPUnit major versions with separate lines for each. The interesting part is the version structure, because the current line targets the older Selenium 2 API rather than WebDriver. **giorgiosironi/phpunit-selenium** — Selenium RC integration for PHPUnit - Repository: https://github.com/giorgiosironi/phpunit-selenium - Website: http://www.phpunit.de/ - Stars: 593 · Forks: 265 - Language: PHP - License: NOASSERTION - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/giorgiosironi-phpunit-selenium ## One test case class and a version matrix This package contains a Selenium2TestCase class that can be used to run end-to-end tests against Selenium 2. That is the whole product, and the interesting engineering is in how it is versioned rather than in what it does. Installation is a single Composer command, and it is a dev dependency: ```bash composer require --dev phpunit/phpunit-selenium ``` The requirements section is a version table with one line per PHPUnit major. Version 9.x supports PHPUnit 9.x and is compatible with PHP 7.3 and later. Version 8.x supports PHPUnit 8.x on PHP 7.2 and later. Version 7.x supports PHPUnit 7.x on PHP 7.1 and later. Below that sit older unsupported lines which the README says will probably see no new releases. The 4.x mainline supports only PHPUnit 6.x and is only compatible with PHP 7. The 3.x line supports PHPUnit 5.x and is only compatible with PHP 5.6 and PHP 7. The 2.x line supports PHPUnit 4.8 and later. That is a package that has shipped roughly one major version per PHPUnit generation, which is the pattern you would expect from something that exists to bridge a moving framework and a moving driver API. The audience is a PHP team running PHPUnit that wants browser coverage, and the version table is the first thing any such team will read. ## The Selenium 2 API constraint, stated plainly The README is unusually direct about the API generation this package speaks. Both the supported lines only work with the Selenium 2 API, using the Selenium2TestCase class. The old 1.x line is not maintained anymore, but will continue to be available for usage of the SeleniumTestCase class. So there is a class name difference between the maintained lines and the old one, which is the kind of detail that catches out a team upgrading across a major version. Selenium 2 is the older API generation that WebDriver superseded as the Selenium project's default, and that distinction matters in practice. The Selenium project moved its default client to WebDriver, and the ecosystem around it, including language bindings and grid tooling, followed. A package that still targets the older API is maintaining a specific compatibility surface with a particular generation of Selenium tooling rather than with Selenium as it is known today. That is not a criticism so much as a fact to plan around. If your CI already runs a Selenium server and your other tests speak one protocol, this package fits. If your infrastructure is WebDriver-based, you are looking at a different package, and the version table here will not help. The other end of the compatibility chain is PHP itself. The supported lines top out at PHP 7.3, which is well behind current PHP releases. ## The Vagrant workflow for running the suite The README documents how to run the test suite, and the method is Vagrant, which is the right call for a suite that needs a browser and a Selenium server. The instruction is to run the following Vagrant commands, and a minimal version of 1.7 is required, and everything will be set up for you. The first start will take some time which depends on the speed of your connection and less, the speed of your computer: ```bash vagrant up vagrant provision vagrant ssh ``` Then, inside the virtual machine, in the shared directory: ```bash cd /vagrant vendor/bin/phpunit Tests ``` The structure of that is sensible. The virtual machine is provisioned once and then reused, the source is mounted at /vagrant so the code on the host is the code under test, and the test suite is run with the project's own vendor binary against the Tests directory. What this buys a team is reproducibility. A Selenium server plus a browser plus the right driver plus the PHP extension is a stack that is painful to install consistently by hand across developer laptops and CI images, and a Vagrant box makes the environment a checked-in artefact rather than a setup document. The cost is the same one Vagrant always carries. The workflow is a second environment to maintain, and a Vagrant-based workflow assumes you are willing to run a full virtual machine for the test suite. ## What is in the tree, and what a maintainer inherits The repository layout shows a package that is small but has accumulated the artefacts of a long life. There is a PHPUnit/ directory, a Tests/ directory, a selenium-1-tests/ directory for the older API, and a build/ directory. The build configuration is Ant based, with a build.xml and a build/ directory, alongside a .travis.yml and a .ci/ directory, so the continuous integration setup is a mix of the two generations of CI configuration. The test bootstrap is a separate file, phpunit-selenium-bootstrap.php, with the PHPUnit configuration in phpunit.xml.dist. A composer.json is present, and the ChangeLog.markdown keeps the release history. For a contributor, the interesting instruction is in the README: please direct pull requests to giorgiosironi/phpunit-selenium for automated testing upon merging, and pull requests should be feature branches containing all the commits you want to propose. That is an unusual arrangement, and it reflects the reality of the project. The upstream repository is where the changes land, and the mirror is a copy. The PHP unit directory with a capital P is also a little odd, and the naming suggests the package is not a modern Composer library laid out by a tool, but a project that grew around an existing structure. ## The maintenance reality of a compatibility shim Two facts from the repository metadata are worth holding together when deciding whether to adopt this. The repository is not archived, and the last push was on 2026-09-24. The package versions in the requirements table are the major lines, so the version numbering here tracks PHPUnit generations rather than the project's own release count. There are no GitHub releases for the project, which for a Packagist package is unusual but consistent with a package released by branch and tag rather than by a release feed. The licence is listed as one GitHub cannot classify, with the note that the details are in the LICENSE file, so anyone planning to use this in a commercial codebase should read that file rather than assume a permissive standard. None of this means the package is broken. A Selenium2TestCase against a Selenium 2 server will do exactly what it says. The point is narrower. This is a compatibility library for a specific pairing of an old PHPUnit and an old driver API, and the fastest way to find out whether it fits your project is to look at the version table and stop there. If your PHPUnit major and PHP version appear in the supported rows, the package is a reasonable answer. If they do not, nothing about the implementation will make it fit. ## Conclusion phpunit-selenium is a good fit for a PHP team that has an existing PHPUnit suite and wants browser-based end-to-end coverage against a Selenium 2 server without writing the driver plumbing by hand, because the package supplies a test case base class and a Vagrant environment that provisions the whole stack. It is a poor fit for a new project, since the current lines target the Selenium 2 API rather than WebDriver, and a poor fit if you are on PHP 8 or above, because the supported lines are pinned to older PHPUnit and PHP combinations. Before adopting, check which PHPUnit major you are on against the version table, confirm the Selenium 2 API is still what your test infrastructure speaks, and read the change log, since the release history for this package has been quiet for a long time. ## FAQ ### How do I install phpunit-selenium? With Composer, as a dev dependency: composer require --dev phpunit/phpunit-selenium. The package is published on Packagist as phpunit/phpunit-selenium and provides a Selenium2TestCase class for running end-to-end tests against Selenium 2. ### Which PHPUnit versions does phpunit-selenium support? Version 9.x supports PHPUnit 9.x on PHP 7.3 and later, version 8.x supports PHPUnit 8.x on PHP 7.2 and later, and version 7.x supports PHPUnit 7.x on PHP 7.1 and later. Older unsupported lines exist for PHPUnit 6.x, 5.x and 4.8. ### How do I run the phpunit-selenium test suite? Using Vagrant, with a minimal version of 1.7 required. Run vagrant up, then vagrant provision, then vagrant ssh, and inside the machine run cd /vagrant followed by vendor/bin/phpunit Tests. The first start takes time depending on your connection and your computer. ### Does phpunit-selenium support the WebDriver API? The README states that both supported lines only work with the Selenium 2 API, using the Selenium2TestCase class. The old 1.x line, which is not maintained anymore, remains available for use of the SeleniumTestCase class. ## Sources - [giorgiosironi/phpunit-selenium on GitHub](https://github.com/giorgiosironi/phpunit-selenium) - [Issues](https://github.com/giorgiosironi/phpunit-selenium/issues) - [Project website](http://www.phpunit.de/) - [README](https://github.com/giorgiosironi/phpunit-selenium/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/giorgiosironi-phpunit-selenium