IfTask boolean issues with predefined properties (Trac #383)

[phing-issues-importer]

Hi all,

I discovered an anomaly in the IfTask in combination with the failureproperty of the PhpUnittestTask.

The environment is Phing 2.3.3 with PHPUnit 3.3.17 on Ubuntu 9.10 using bash.

If you initialize the property used as failureproperty in the PhpUnittestTask through a PropertyTask first, the IfTask does no longer work as expected. I attached three example build scripts to clarify this, but in a nutshell it is like this:

Assuming <phpunit failureproperty="unittestFailed"> and

  <if>
    <equals arg1="${unittestFailed}" arg2="1" />
    <then>

we have the following behaviour:

• without initializing the unittestFailed property the if condition works as expected
• with the if condition will always enter the else-branch, regardless of the state of the unittests.
• with the if condition will always enter the then-branch, regardless of the state of the unittests.

This is not really a bug in my opinion, more a unclean behaviour. If might lead to incorrect behaviour however, if one and the same property (in this case unittestFailed) is used as common status flag for multiple tests which all have to go through.

Regards, Dominique

http://www.st/webdevelopment.de

Migrated from https://www.phing.info/trac/ticket/383

{
    "status": "reopened", 
    "changetime": "2016-10-07T08:28:55", 
    "description": "Hi all,\n\nI discovered an anomaly in the IfTask in combination with the failureproperty of the PhpUnittestTask.\n\nThe environment is Phing 2.3.3 with PHPUnit 3.3.17 on Ubuntu 9.10 using bash.\n\nIf you initialize the property used as failureproperty in the PhpUnittestTask through a PropertyTask first, the IfTask does no longer work as expected.\nI attached three example build scripts to clarify this, but in a nutshell it is like this:\n\nAssuming \n  <phpunit failureproperty=\"unittestFailed\">\nand \n  <if>\n    <equals arg1=\"${unittestFailed}\" arg2=\"1\" />\n    <then>\nwe have the following behaviour:\n\n- without initializing the unittestFailed property the if condition works as expected\n- with <property name=\"unittestFailed\" value=\"false\" /> the if condition will always enter the else-branch, regardless of the state of the unittests.\n- with <property name=\"unittestFailed\" value=\"true\" /> the if condition will always enter the then-branch, regardless of the state of the unittests.\n\nThis is not really a bug in my opinion, more a unclean behaviour. If might lead to incorrect behaviour however, if one and the same property (in this case unittestFailed) is used as common status flag for multiple tests which all have to go through.\n\nRegards,\nDominique\n\n--\nhttp://www.st/webdevelopment.de\n", 
    "reporter": "saloon12yrd@yahoo.com", 
    "cc": "Mp@webfactory.de", 
    "resolution": "", 
    "_ts": "1475828935569836", 
    "component": "phing-core", 
    "summary": "IfTask boolean issues with predefined properties", 
    "priority": "major", 
    "keywords": "properties, PhpUnitTask, boolean, ifTask", 
    "version": "2.3.3", 
    "time": "2009-11-17T04:47:16", 
    "milestone": "4.0", 
    "owner": "mp", 
    "type": "defect"
}

[phing-issues-importer]

Trac update at 20091117T04:47:36: anonymous changed attachment from "" to "bug_works.xml"

[phing-issues-importer]

Trac update at 20091117T04:49:15: anonymous changed attachment from "" to "bug_fails.xml"

[phing-issues-importer]

Trac update at 20091117T04:49:25: anonymous changed attachment from "" to "bug_fails2.xml"

[phing-issues-importer]

Trac update at 20091125T19:25:52:

• mrook commented:

You are completely right - the ambiguity lies in the distinction between user and system properties, something we need to look at properly. Therefore I'm moving this to the 3.0 branch for now. Thanks for the report!

• mrook changed keywords from "PhpUnitTask, boolean, ifTask" to "properties, PhpUnitTask, boolean, ifTask"
• mrook changed milestone from "2.4.0RC3" to "3.0"
• mrook changed priority from "minor" to "major"

[phing-issues-importer]

Trac update at 20110619T06:23:06: mp commented:

Without having run the examples provided >:-) I'd guess the problem is that the task calls setNewProperty:

324                 $this->project->setNewProperty($this->failureproperty, true);

that should just be setProperty().

Of course it still fails if you set that property on the command line. Don't think that is an issue.

[phing-issues-importer]

Trac update at 20110619T06:24:12: mp changed cc from "" to "Mp@webfactory.de"

[phing-issues-importer]

Trac update at 20110622T09:20:32: mp commented:

(In [1177]) Remove automagical conversion of strings to booleans. See http://phing.tigris.org/ds/viewMessage.do?dsForumId=1079&dsMessageId=2771568.

Refs #539, #534, https://www.phing.info/trac/ticket/376, #533.

Introduces a BC break for existing tasks.

[phing-issues-importer]

Trac update at 20110622T09:25:59: mrook changed milestone from "TBD" to "2.5.0"

[phing-issues-importer]

Trac update at 20110622T09:26:10: mrook changed owner from "mrook" to "mp"

[phing-issues-importer]

Trac update at 20110622T14:05:34:

• mp commented:

(In [1185]) Closes #383.

Note that you should use to check for failures.

• mp changed resolution from "" to "fixed"
• mp changed status from "new" to "closed"

[phing-issues-importer]

Trac update at 20150104T20:28:18:

• mrook commented:

Re-opening to track rebuilding of the 3.0 branch.

• mrook changed resolution from "fixed" to ""
• mrook changed status from "closed" to "reopened"

[phing-issues-importer]

Trac update at 20161007T08:28:55:

• mrook commented:

Milestone renamed

• mrook changed milestone from "3.0" to "4.0"

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because it has not had recent activity. Thank you for your contributions.