Skip to content

Added note about using the Validator TypeTestCase in form unit testing #7587

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 9 commits into from
Jan 10, 2018

Conversation

pierredup
Copy link
Contributor

This update ads the usage of the validator TypeTestCase class to use for testing when validation is required.

Copy link
Contributor

@HeahDude HeahDude left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@xabbuh
Copy link
Member

xabbuh commented Mar 7, 2017

Actually, after thinking about this again I am 👎 on merging the PR as is. We usually don't want to guarantee BC for classes that live inside the Tests namespace (that's why there is a Test namespace that contains classes that are meant to be used as base classes for userland code).

@pierredup
Copy link
Contributor Author

pierredup commented Mar 7, 2017

What would you suggest needs to change? Should the class be moved to the Test namespace under a different name (Something like ValidatorTestCase)?

@xabbuh
Copy link
Member

xabbuh commented Mar 7, 2017

I am not completely settled on that yet. The main issue is: What if you need another extension? Which base class do you extended then (supposed there is a base class for the other extension as well)?

@xabbuh
Copy link
Member

xabbuh commented Mar 7, 2017

I think the best is to open an issue on the code repository and discuss the matter over there first.

@wouterj
Copy link
Member

wouterj commented Mar 7, 2017

While I like your suggestion, I don't think we should document classes that live in *\Tests\*. These classes aren't part of the BC promise and thus shouldn't be used by other packages.

Instead, we should update our example to fix the code. This probably means finishing #6463 .

However, if it turns out to be a very nice addition to unit testing, the class might need to be moved to Symfony\Component\Form\Test\ValidatorTypeTestCase so it can be used by other packages. As I've seen this class used by quite a few packages, I suggest submitting a PR doing so against the code repository. Are you maybe willing to do that?

@pierredup
Copy link
Contributor Author

Hence my original PR that added the validator to the main base class with an extension point to register custom extensions (and other core extensions can be added in the same place).
I'll open another PR following that approach again and see what discussions come out of it

@wouterj
Copy link
Member

wouterj commented Mar 7, 2017

Sorry if I duplicated something that's already done. I lost overview with all these referenced PRs. 😇

@pierredup
Copy link
Contributor Author

pierredup commented Mar 7, 2017

I would suggest updating the standard base class to include the validator extension, and remove (deprecate?) the one under Tests so that there is one class to extend, both for userland and internal tests (also checking that the validator is installed before registering the extension).
I'll open a PR on the code repository for this and wait for feedback

@wouterj
Copy link
Member

wouterj commented Mar 7, 2017

I would suggest updating the standard base class to include the validator extension

I don't think this will be accepted by the core team. The form component can be used standalone without the validator, so it should at least be optional. You may create a trait with a getValidatorExtension() method that can be easily called when extending the TypeTestCase?

@pierredup
Copy link
Contributor Author

also checking that the validator is installed before registering the extension

This should cover the case where the form component is used in standalone mode and the validator is not installed.

@@ -157,40 +157,49 @@ before creating the parent form using the ``PreloadedExtension`` class::
be getting errors that are not related to the form you are currently
testing but to its children.

Forms Using Validation
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pierredup Can you remove this section? We can then still merge your fixes to the class namespaces which is still a legit fix.

@pierredup pierredup force-pushed the forms-unit-testing branch from 66a009b to 6fda2df Compare June 24, 2017 13:50
return array(
new ValidatorExtension($validator),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should these changes also be reverted?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so

@HeahDude HeahDude added this to the 2.7 milestone Jul 29, 2017
fabpot added a commit to symfony/symfony that referenced this pull request Sep 27, 2017
…to base TypeTestCase (pierredup)

This PR was squashed before being merged into the 3.4 branch (closes #21960).

Discussion
----------

Remove Validator\TypeTestCase and add validator logic to base TypeTestCase

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no/possibly
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | N/A
| License       | MIT
| Doc PR        | symfony/symfony-docs#7587

Based on a discussion in the docs, users should not really extend classes in the `Tests` namespace. This means that if you want to unit test forms, you need to extend the `Test\TypeTestCase` class which doesn't have the validation logic (Not adding the validator extension gives an error if you use the `constraints` option in your forms).
So I propose to remove the `Validator\TypeTestCase` class (or it can possibly be deprecated if it is wrongly used by someone), and add the validator extension logic to the base `TypTestCase` class.

The benefit is that there is only one class to extend (both for internal or userland tests), and it makes it easy to add more core extensions if necessary.

The one part that I don't like too much at the moment, is keeping the extension in the `getExtensions` method. This means that you extend the class and need to register custom extensions, that you would need to do `return array_merge(parent::getExtensions(), ... ` (only in the case when you want core extensions enabled). So I don't know if we rather want to add a private method like `getCoreExtensions`?

Commits
-------

5ab5010 Remove Validator\TypeTestCase and add validator logic to base TypeTestCase
@javiereguiluz
Copy link
Member

What can we do to make this PR mergeable? Thanks!

@HeahDude
Copy link
Contributor

@javiereguiluz Revert everything excepted namespaces modifications like https://github.com/symfony/symfony-docs/pull/7587/files#diff-d9a34263773b4fe7719e18118a10e628R204.

@javiereguiluz
Copy link
Member

@pierredup we had to revert part of your proposed changes, but merged others. Thanks for your contribution!

@javiereguiluz javiereguiluz merged commit c495b92 into symfony:2.7 Jan 10, 2018
javiereguiluz added a commit that referenced this pull request Jan 10, 2018
… unit testing (pierredup, javiereguiluz)

This PR was merged into the 2.7 branch.

Discussion
----------

Added note about using the Validator TypeTestCase in form unit testing

This update ads the usage of the validator TypeTestCase class to use for testing when validation is required.

Commits
-------

c495b92 Readded a blank line
ff1bd8e Reverted some changes
f0887ae Remove section about forms using validation
6fda2df Removed extra class
cf0f9e6 Update fomr testing sentence
070b2c0 Renamed TestedTypeTests to TestedTypeTest
d17821a Fix heading underlining
d4979eb Fix typos
3e6dc19 Add docs about the validator TypeTestCase class
@pierredup pierredup deleted the forms-unit-testing branch January 10, 2018 09:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants