3

In a php project that I maintain I have a database structure without migrations, hence no way to reproduce it or make on the fly a test database.

And the queries used to be performed on them are rather complex ones. The pattern in code used with them is (I try to show a generelized preview of the problem):

public function someMethod(PDO $connection, string $param) {

  $sql="^some complex sql query^";
  $pdo->prepare($sql);
  $pdo->bindParam('param',$param);
  $stmt->execute();

  return $stmt->fetchAll();
}

In order to test this function I created a duplicate database and from that I deleted all the production data keeping the least minimal. I use the following testing approach when I write phphunit test

  1. Populate the database with test data.
  2. Run the method.
  3. Do my Assertions.
  4. Delete the test data manually using Delete sql statements.

Did this approach creates a Unit test for my application or an Integration one. Keep in mind that the whole logic is implemented in an SQL query instead on the php layer.

For example a query like that:

Select
    value,
    CASE 
     WHEN "time"::time < '12:00' and "time"::time > '00:00' then true 
    ELSE 
      false end as observed_in_morning  
from 
  observations

The example above the logic that indicates whether an observation happened in me morning or not is written on the sql statement, clearly a business logic.

So a test testing whether an observation happened in the morning is a unit test or an integration one?

Dimitrios Desyllas
  • 451
  • 2
  • 4
  • 16
  • Its an integration test because it needs the database AND the code – Ewan Jan 02 '20 at 15:55
  • I have all my database tests in the normal unit test framework. The only thing that I might be doing differently is that one of the unit tests for the database is actually a dummy and replicates my sample database to a database under test. So, I can have a clean one when I want it, rather than having to delete all the changes. – Rohit Gupta Oct 07 '22 at 01:16

1 Answers1

8

Purists won't call any test a "unit test" which involves a database. Other purists won't call a test an "integration test" when there are not at least two components involved (and a platform like the SQL engine of the DB usually does not count as a component).

And some not so puristic people call everything a unit test which gets started by an automatic testing tool like "phpunit". Other people call everything an integration test which does involve a database.

Honestly, these names don't really matter as long as in the group of people you are working with you don't create too much confusion. If you want to be safe, call this neither unit test nor integration test, but an automated functional test.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565