Question

I’m a relatively new convert to unit testing in general and I’ve run into a stumbling block here:

How do I test code that connects to and performs operations on a remote FTP server using PHP’s built-in ftp functions? Some googling turned up a quick mocking option for Java (MockFtpServer), but nothing readily available for PHP.

I have a suspicion the answer may be to create a wrapper class for PHP’s ftp functions that can subsequently be stubbed/mocked to mimic successful/unsuccessful ftp operations, but I’d really appreciate some input from people who are smarter than me!

Please note that I’ve been working with PHPUnit and require assistance with that framework specifically.

---

As per the request from @hakre the simplified code I want to test looks like the below. I’m essentially asking the best way to test:

public function connect($conn_name, $opt=array())
{
  if ($this->ping($conn_name)) {
    return TRUE;
  }

  $r = FALSE;

  try {    
    if ($this->conns[$conn_name] = ftp_connect($opt['host'])) {
      ftp_login($this->conns[$conn_name], $opt['user'], $opt['pass']);
    }
    $r = TRUE;
  } catch(FtpException $e) {
    // there was a problem with the ftp operation and the
    // custom error handler threw an exception
  }

  return $r;
}

UPDATE/SOLUTION SUMMARY

Problem Summary

I wasn’t sure how to test methods in isolation that required communicating with a remote FTP server. How are you supposed to test being able to connect to an outside resource you have no control over, right?

Solution Summary

Create an adapter class for the FTP operations, (methods: connect, ping, etc). This adapter class is then easily stubbed to return specific values when testing other code that uses the adapter to perform FTP operations.

UPDATE 2

I recently came across a nifty trick using namespaces in your tests that allows you to “mock” PHP’s built-in functions. While the adapter was the right way to go in my particular case, this may be helpful to others in similar situations:

Mocking php global functions for unit testing

Answer 1

Two approaches that come to mind:

1. Create two adapters for your FTP class:

   1. The “real” one that uses PHP’s ftp functions to connect to the remote server, etc.

   2. A “mock” one that does not actually connect to anything and only returns seeded data.

      The FTP class’ connect() method then looks like this:

      public function connect($name, $opt=array())
      {
        return $this->getAdapter()->connect($name, $opt);
      }
      

      The mock adapter might look something like this:

      class FTPMockAdapter
        implements IFTPAdapter
      {
        protected $_seeded = array();
      
        public function connect($name, $opt=array())
        {
          return $this->_seeded['connect'][serialize(compact('name', 'opt'))];
        }
      
        public function seed($data, $method, $opt)
        {
          $this->_seeded[$method][serialize($opt)] = $data;
        }
      }
      

      In your test, you would then seed the adapter with a result and verify that connect() is getting called appropriately:

      public function setUp(  )
      {
        $this->_adapter = new FTPMockAdapter();
        $this->_fixture->setAdapter($this->_adapter);
      }
      
      /** This test is worthless for testing the FTP class, as it
       *    basically only tests the mock adapter, but hopefully
       *    it at least illustrates the idea at work.
       */
      public function testConnect(  )
      {
        $name    = '...';
        $opt     = array(...);
        $success = true
      
        // Seed the connection response to the adapter.
        $this->_adapter->seed($success, 'connect', compact('name', 'opt'));
      
        // Invoke the fixture's connect() method and make sure it invokes the
        //  adapter properly.
        $this->assertEquals($success, $this->_fixture->connect($name, $opt),
          'Expected connect() to connect to correct server.'
        );
      }
      

   In the above test case, setUp() injects the mock adapter so that tests can invoke the FTP class’ connect() method without actually triggering an FTP connection. The test then seeds the adapter with a result that will only be returned if the adapter’s connect() method were called with the correct parameters.

   The advantage to this method is that you can customize the behavior of the mock object, and it keeps all of the code in one place if you need to use the mock across several test cases.

   The disadvantages to this method are that you have to duplicate a lot of functionality that has already been built (see approach #2), and arguably you’ve now introduced another class that you have to write tests for.

2. An alternative is to use PHPUnit’s mocking framework to create dynamic mock objects in your test. You’ll still need to inject an adapter, but you can create it on-the-fly:

   public function setUp(  )
   {
     $this->_adapter = $this->getMock('FTPAdapter');
     $this->_fixture->setAdapter($this->_adapter);
   }
   
   public function testConnect(  )
   {
     $name = '...';
     $opt  = array(...);
   
     $this->_adapter
       ->expects($this->once())
       ->method('connect')
       ->with($this->equalTo($name), $this->equalTo($opt))
       ->will($this->returnValue(true));
   
     $this->assertTrue($this->_fixture->connect($name, $opt),
       'Expected connect() to connect to correct server.'
     );
   }
   

   Note that the above test mocks the adapter for the FTP class, not the FTP class itself, as that would be a rather silly thing to do.

   This approach has advantages over the previous approach:

   • You’re not creating any new classes, and PHPUnit’s mocking framework has its own test coverage, so you don’t have to write tests for the mock class.
   • The test acts as documentation for what is happening ‘under the hood’ (although some might contend this is not actually a good thing).

   There are some disadvantages to this approach, however:

   • It’s rather slow (in terms of performance) compared to the previous approach.
   • You have to write a lot of extra code in every test that uses the mock (although you can refactor common operations to mitigate some of this).

   See http://phpunit.de/manual/current/en/test-doubles.html#test-doubles.mock-objects for more information.