From ad88f3d45c20ef66d647a6c123bb14dbd9e8546f Mon Sep 17 00:00:00 2001 From: Sonata CI Date: Wed, 27 Jan 2021 09:42:04 +0000 Subject: [PATCH] DevKit updates (#262) --- CONTRIBUTING.md | 17 +---------------- 1 file changed, 1 insertion(+), 16 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c2bac40..76d3f45 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -148,6 +148,7 @@ If your PR contains an addition, a new feature, this one has to be fully covered Some rules have to be respected about the test: +* Prefer [the built-in test doubles implementation](https://phpunit.de/manual/current/en/test-doubles.html) over prophecy. * Annotations about coverage are prohibited. This concerns: * `@covers` * `@coversDefaultClass` @@ -161,22 +162,6 @@ Some rules have to be respected about the test: * Most of the time, the test class SHOULD have the same name as the targeted class, suffixed by `Test`. * The `@expectedException*` annotations are prohibited. Use `PHPUnit_Framework_TestCase::setExpectedException()`. -##### Using test doubles - -Historically, Sonata has been using [the built-in test doubles implementation](https://phpunit.de/manual/current/en/test-doubles.html), -but [started to use Prophecy](https://github.com/sonata-project/dev-kit/issues/89). -This means the current Sonata codebase currently uses both implementations. - -If you want to contribute a test that uses test doubles, please follow these rules : - -1. All new test classes MUST use built-in test double implementation. -2. If you are changing an existing test method, you MUST use the same implementation it already uses, -and focus on the goal of your PR and only on that. -3. If you are changing an existing test class, you MUST use the same implementation it already uses, -to be more consistent. -4. You MAY submit a PR that migrates a test class from Prophecy to the built-in test double implementation, -but it MUST migrate it entirely. The PR SHOULD only be about the migration. - ### Writing a Pull Request #### Subject