Skip to content
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

Allow to define options to display colors #1527

Merged
merged 1 commit into from
Dec 15, 2014
Merged

Allow to define options to display colors #1527

merged 1 commit into from
Dec 15, 2014

Conversation

henriquemoody
Copy link
Contributor

Related to #1458 and #1525.

It's basically the same idea of #1526 but this also allows you to use the configuration file to define the colors while #1526 only allows you to do it by command line.

@jbladen
Copy link

jbladen commented Dec 12, 2014

Doesn't this break BC by enforcing that --colors must now have an argument?

@henriquemoody
Copy link
Contributor Author

Exactly the opposite, it doesn't.

{
$currentValue = strtolower($value);

if (in_array($currentValue, array('auto', 'tty', 'if-tty'))) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think 'true' missing here ?

@henriquemoody
Copy link
Contributor Author

I will close that pull request in favor of #1526, I don't @sebastianbergmann is going to have a different opinion of you guys.
@jbladen feel free to take the documentation part of this pull request to yours.

@henriquemoody
Copy link
Contributor Author

I decided to change some stuff, create a PHPT test and keep the pull request opened for a while.

sebastianbergmann added a commit that referenced this pull request Dec 15, 2014
Allow to define options to display colors
@sebastianbergmann sebastianbergmann merged commit 6c94349 into sebastianbergmann:master Dec 15, 2014
@sebastianbergmann sebastianbergmann added this to the PHPUnit 4.6 milestone Dec 15, 2014
@remicollet
Copy link
Contributor

:-(

@sebastianbergmann
Copy link
Owner

@remicollet What's wrong?

@remicollet
Copy link
Contributor

The old colors=true in configuration file make terribly ugly output in build log (reason for the change to detect if colors are possible)

Allowing colors=always, which is going to be used by some projects (to get colors in travis) will put us in the same bad situation as previous, having to patch tons of configuration files.

More, it will make the configuration file (which use colors=always) incompatible with older phpunit version, thus, raising dependency on phpunit 4.x only for this "cosmetic" feature

I still really think that change need to be applied in hasColorSupport() to properly detect case where colors are possible, and that, if this "force" mode is allowed, it should be only allowed from command line, not from configuration file.

@sebastianbergmann
Copy link
Owner

I understand your perspective, Remi, but I think for PHPUnit we should focus on its users and not on the users of its users, if that makes sense. Patches to improve hasColorSupport() are appreciated as well as disallowing force in the configuration file.

@remicollet
Copy link
Contributor

@sebastianbergmann thanks
See #1529

@henriquemoody henriquemoody deleted the colors branch December 15, 2014 13:00
@henriquemoody
Copy link
Contributor Author

@remicollet, I saw what you did on #1529, but as you already know what you tried to fix in #1458 was not fixed yet and it must be fixed on Environment.

Now you can use always, auto and never but the BC (true and false) was kept and this the most important. You said it is incompatible with older PHPUnit versions but this is a new feature, so IMHO it's perfectly acceptable, unless new features are not allowed in the configuration file.

There is quite difference between never, auto and always I think if a person want use it, specifically, is for a good reason.

@remicollet
Copy link
Contributor

@henriquemoody sorry, I haven't understood your last comment :(

My feeling:

  • colors enable when no support for colors was fixed by 1458
  • colors not enabled when supported is a new bug in Environment / hasColorSupport
  • new options colors=always is only a (poor) workaround to this second bug.

I don't say new feature are not allowed in configuration. I just mean that some project are going to use colors="always" and raise dependency on phpunit 4.6 just for this "comestic", which is terrible tricky.

I think hasColorSupport() is enough for me. If people want to improve it, they can (ex add detection for Travis), but I really don't care:

  • Having colors where not supported is critical (reason for 1529)
  • Not having colors where supported is NOT critical.

Remember: PHPUnit is a tool to run unit test. I really think we should focus on test feature.

@henriquemoody
Copy link
Contributor Author

colors enable when no support for colors was fixed by 1458

#1458 may fix the problem of having colors=true in a Linux environment but for me it's desperate solution since it creates duplications. This checking is already made in the PHPUnit_TextUI_ResultPrinter, which is, in fact, the responsible for it.

colors not enabled when supported is a new bug in Environment / hasColorSupport

As I can see, looks like you have cases when is not supported but it still is enabled.

new options colors=always is only a (poor) workaround to this second bug.

No, it's not, it's a new feature. I'm sure you know grep, for example, does the same. Now you can pipe the output and still have colors, you can read it with | less -R, for example.

BTW, hasColorSupport() as you can see in its docblock it is just a copy of Symfony\Console and I haven't seem people reporting bugs like that, maybe there is something I didn't catch yet.

Remember: PHPUnit is a tool to run unit test. I really think we should focus on test feature.

Agreed, but it doesn't mean we don't have to care about anything else, I think that's the same reason you sent #1458.

rugamaga added a commit to rugamaga/dietcube that referenced this pull request Mar 21, 2020
fix ci errors by following change of phpunit.xml's attribute usage.

* Deleted `colors="auto"`.
currently, `colors` value must be `true` or `false`, and default is `auto`.
(and all current supported versions are default `auto`)
see also: sebastianbergmann/phpunit#1527

* Move whitelist setting attributes into `whitelist` tag attributes
targets:
- `addUncoveredFilesFromWhitelist`
- `processUncoveredFilesFromWhitelist`
those two kind of attributes have deleted from `phpunit` tag.

* Deleted `logIncompleteSkipped` attribute
`logIncompleteSkipped` is no longer allowed in phpunit.xml.
and because, we have no `skipped` test, we don't need it.
so, simply I delete it.
rugamaga added a commit to rugamaga/dietcube that referenced this pull request Mar 21, 2020
fix ci errors by following change of phpunit.xml's attribute usage.

* Deleted `colors="auto"`.
currently, `colors` value must be `true` or `false`, and default is `auto`.
(and all current supported versions are default `auto`)
see also: sebastianbergmann/phpunit#1527

* Move whitelist setting attributes into `whitelist` tag attributes
targets:
- `addUncoveredFilesFromWhitelist`
- `processUncoveredFilesFromWhitelist`
those two kind of attributes have deleted from `phpunit` tag.

* Deleted `logIncompleteSkipped` attribute
`logIncompleteSkipped` is no longer allowed in phpunit.xml.
and because, we have no `skipped` test, we don't need it.
so, simply I delete it.

* Add testsuite `name`
In latest version, `name` attribute is must be set.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants