php integration testing
v1.0 release
데이터베이스 및 기타 일반적인 인프라 관련 테스트를 위한 PHP의 통합 테스트 라이브러리입니다.
이는 다양한 이벤트를 연결하고 픽스쳐를 실행하는 PHPUnit용 확장 세트로 개발되었습니다.
현재 다음 PHPUnit 후크에서 사용자 정의 픽스쳐를 실행할 수 있습니다:
BeforeFirstTest
테스트 전
테스트 후
마지막 테스트 후
WIP: WithBeforeTestFixtureName 및 WithAfterTestFixtureName을 사용한 AMQP 특정 테스트 픽스처
PHPUnit
작곡가를 통해
composer require --dev hrodic/php-integration-testing
PHPUnit 구성 XML 파일에서 구성과 함께 확장을 지정해야 합니다.
사용할 구성 파일 이름을 지정할 수 있습니다. 기본값은 .integration-testing.json입니다.
<extensions> <extension class="IntegrationTestingPHPUnitRunnerExtensionHandler"> <arguments> <string>.integration-testing.json</string> </arguments> </extension> </extensions>
phpunit-integration.xml.dist 예제도 확인하세요.
PHPUnit 확장에 대한 도움이 필요하면 공식 문서를 참조하세요.
MySQL 또는 MariaDB의 통합을 테스트해야 하는 경우 PDO 드라이버 확장을 사용하십시오.
json 구성 파일에서 찾을 수 있는 구성 매개변수가 필요합니다.
가장 중요한 매개변수는 DSN, 데이터베이스의 사용자 이름 및 비밀번호 + 일부 고정 경로 정의입니다.
예:
"pdo": {
"dsn": "mysql:host=localhost:3306;dbname=test;charset=utf8",
"user": "test",
"password": "test",
"fixtures": {
"beforeFirstTest": {
"path": "tests/fixtures/before-first-test",
"extension": "sql"
},
"beforeTest": {
"path": "tests/fixtures/before-test",
"extension": "sql"
},
"afterTest": {
"path": "tests/fixtures/after-test"
},
"afterLastTest": {
"path": "tests/fixtures/after-last-test"
}
}
},AMQP(RabbitMQ에서 테스트됨) 고정 장치 및 작업을 시험해 볼 수도 있습니다.
구성 파일을 사용하여 연결 및 후크 작업을 구성합니다.
참고:
후크 정의는 선택 사항이므로 필요한 정의만 구성하면 됩니다.
beforeFirstTest 및 beforeTest 에만 메시지를 게시할 수 있습니다.
4개 후크 모두에서 대기열을 제거할 수 있습니다.
게시할 메시지 본문의 파일 확장자는 기본값이 json 입니다.
교환기를 direct 로 구성한 경우 routing_key 사용하세요. fanout 인 경우 빈 문자열로 정의할 수 있습니다.
"amqp": {
"host": "localhost",
"port": 5672,
"user": "test",
"password": "test",
"vhost": "/",
"fixtures": {
"beforeFirstTest": {
"purgeQueues": [
"before-first-test-queue"
],
"publishMessages": [
{
"exchange": "test-exchange",
"queue": "before-first-test-queue",
"routing_key": "before-first-test",
"path": "tests/fixtures/before-first-test",
"extension": "json"
}
]
},
"beforeTest": {
"purgeQueues": [
"before-test-queue"
],
"publishMessages": [
{
"exchange": "test-exchange",
"queue": "before-test-queue",
"routing_key": "before-test",
"path": "tests/fixtures/before-test"
}
]
},
"afterTest": {
"purgeQueues": [
"before-test-queue"
]
},
"afterLastTest": {
"purgeQueues": []
}
}
}PDO 고정물은 단지 SQL 파일일 뿐입니다.
특정 후크 카테고리에 위치한 모든 픽스처는 트랜잭션 내에서 순서대로 실행됩니다.
각 단계에서 SQL을 생성하는 방법과 데이터베이스의 무결성은 귀하에게 달려 있습니다. 라이브러리는 처음에 고정 장치를 설정하고 각 테스트 후에 혼란을 정리하는 것이 일반적이지만 어떤 규칙도 따르도록 강요하지 않습니다.
생성, 삽입, 삭제 등 사용자가 수행하도록 구성한 모든 작업을 수행할 수 있습니다. 테스트 데이터베이스는 실제 데이터베이스와 격리되어야 한다는 점을 기억하세요!
네 가지 고정 후크 유형 모두 원하는 디렉토리에 배치할 수 있습니다.
모든 특정 테스트에서 발생하는 BeforeTest 및 AfterTest 후크의 경우 WithBeforeTestFixtureName 및/또는 WithAfterTestFixtureName 인터페이스를 구현하여 일반 Before 및 After 픽스처 바로 뒤에 실행될 특정 픽스처를 제공할 수도 있습니다.
final class YourIntegrationTest extends TestCase implements WithBeforeTestFixtureName, WithAfterTestFixtureName
{
private const FIXTURE_NAME = 'pdo-integration-test';
public static function getAfterTestFixtureName(): string
{
return self::FIXTURE_NAME;
}
public static function getBeforeTestFixtureName(): string
{
return self::FIXTURE_NAME;
}
public function testYourRepositoryHere(): void
{
// arrange
// act
// assert against real database (your fixtures are already there!)
}
}확장은 메소드가 정의되었는지 확인하고 이를 사용하여 기본 BEFORE_TEST_PDO_FIXTURES_PATH 및 AFTER_TEST_PDO_FIXTURES_PATH 디렉토리 내의 하위 디렉토리를 찾습니다.
테스트/픽스처 폴더를 살펴보면 픽스처를 구성하는 방법에 대한 예를 볼 수 있습니다. 여러 개의 SQL 파일을 가질 수 있으며 확장 프로그램은 해당 파일을 순서대로 읽고 실행합니다.
├── after-last-test # AFTER_LAST_TEST_PDO_FIXTURES_PATH, executed once, at the end │ └── 01.sql ├── after-test # AFTER_TEST_PDO_FIXTURES_PATH, executed after each test │ ├── 01.sql │ └── pdo-integration-test # executed after each test inside the class that defines this fixture name │ └── 01.sql ├── before-first-test # BEFORE_FIRST_TEST_PDO_FIXTURES_PATH, executed once, at the beginning │ └── 01.sql └── before-test # BEFORE_TEST_PDO_FIXTURES_PATH, executed before each test ├── 01.sql └── pdo-integration-test # executed before each test inside the class that defines this fixture name └── 01.sql
통합 테스트를 위해서는 일부 인프라가 마련되어 있어야 합니다.
이 라이브러리는 액세스 가능한 데이터베이스나 기타 인프라가 이미 마련되어 있고 데이터베이스가 생성되었다고 가정합니다(영감을 얻으려면 docker-compose.yml 파일을 확인할 수 있음).
