Skip to content
This repository has been archived by the owner on Aug 6, 2023. It is now read-only.

failed tests #105

Open
till opened this issue Nov 5, 2012 · 11 comments
Open

failed tests #105

till opened this issue Nov 5, 2012 · 11 comments
Labels
Milestone

Comments

@till
Copy link
Member

till commented Nov 5, 2012

Failed tests:

/Users/till/Documents/workspaces/Pyrus/tests/AtomicFileTransaction/AtomicFileTransactionClass/createOrOpenPath/createoropenpath.fail.fp.stream.empty.phpt
/Users/till/Documents/workspaces/Pyrus/tests/AtomicFileTransaction/TransactionClass/createOrOpenPath/createoropenpath.fail.fp.stream.empty.phpt
/Users/till/Documents/workspaces/Pyrus/tests/Custom/Command/basic.phpt
/Users/till/Documents/workspaces/Pyrus/tests/Dependency_Validator/validateArchDependency/archdep.extra.phpt
/Users/till/Documents/workspaces/Pyrus/tests/Package/parsePackageDescription.phpt
/Users/till/Documents/workspaces/Pyrus/tests/PackageFile_Parser_v2/test_2.0.phpt
/Users/till/Documents/workspaces/Pyrus/tests/PackageFile_Parser_v2/test_2.1.phpt
/Users/till/Documents/workspaces/Pyrus/tests/PackageFile_v2_Validator/validate.newobject.packaging.phpt
/Users/till/Documents/workspaces/Pyrus/tests/PackageFile_v2_Validator/validate.newobject.phpt
/Users/till/Documents/workspaces/Pyrus/tests/Registry/Pear1/getdependentpackages/getdependentpackages.basic.phpt
/Users/till/Documents/workspaces/Pyrus/tests/RemotePackage/invalidpackage.phpt
/Users/till/Documents/workspaces/Pyrus/tests/ScriptFrontend/Commands/build.phpt
/Users/till/Documents/workspaces/Pyrus/tests/ScriptFrontend/Commands/upgradeRegistry.phpt
/Users/till/Documents/workspaces/Pyrus/tests/Validate/validatepackagename.extends.failure.phpt
/Users/till/Documents/workspaces/Pyrus/tests/Validate/validatepackagename.extends.phpt
/Users/till/Documents/workspaces/Pyrus/tests/Validate/validateversion.alpha.extends.2.0.0a1.phpt
/Users/till/Documents/workspaces/Pyrus/tests/Validate/validateversion.failure.extends.alpha.0.1.0.phpt
/Users/till/Documents/workspaces/Pyrus/tests/Validate/validateversion.failure.extends.alpha.00.1.0.phpt
/Users/till/Documents/workspaces/Pyrus/tests/Validate/validateversion.failure.extends.alpha.2.0.0.phpt
/Users/till/Documents/workspaces/Pyrus/tests/Validate/validateversion.failure.extends.alpha.2.0.000.phpt
/Users/till/Documents/workspaces/Pyrus/tests/Validate/validateversion.failure.extends.alpha.2.0.0001.phpt
/Users/till/Documents/workspaces/Pyrus/tests/Validate/validateversion.failure.extends.alpha.2.0.1.phpt
/Users/till/Documents/workspaces/Pyrus/tests/Validate/validateversion.failure.extends.alpha.phpt
/Users/till/Documents/workspaces/Pyrus/tests/Validate/validateversion.failure.extends.stable.phpt
@till
Copy link
Member Author

till commented Nov 5, 2012

@saltybeagle I think this is the only thing that keeps us from alpha5. I think it's necessary to get these enabled so we can get CI on the way and then hopefully never again break features which are covered by a test. What do you think it takes to get this resolved?

@till
Copy link
Member Author

till commented Nov 6, 2012

cc @saltybeagle

tests/Custom/Command/basic.phpt

@cweiske helped me debug this yesterday. The commit breaking the test is ca074ae — how do we deal with this? exit() probably shouldn't happen inside a class, but outside in a wrapper of some kind to keep code testible?

till added a commit that referenced this issue Nov 6, 2012
Change: ->run() should (!) always return an exit code, we exit() in the wrapper

Related ticket: #105
@saltybeagle
Copy link
Member

That looks fine to me. There are about half a dozen other exit calls that remain within ScriptFrontend\Commands — as for test-ability, testing the exit calls is not difficult at all using phpt

@till
Copy link
Member Author

till commented Nov 6, 2012

@saltybeagle The problem is that a lot of tests rely on ob_start() to fetch output. exit() just drops that to stdout. Not sure if I want to fix that up, or rather have the class provide a clean exit code and then exit() in scripts/pyrus where it seems more appropriate?

@till
Copy link
Member Author

till commented Nov 6, 2012

Looking at Pyrus\ScriptFrontend\Commands — I think most of that should be split up in sub-classes. But I don't wanna start this before we complete alpha5.

@cweiske
Copy link
Contributor

cweiske commented Nov 6, 2012

phpt brings the solution, brett is correct with that. We should just use propert --EXPECT-- sections

@saltybeagle: why was ob_start() used at all instead of EXPECT?

@till
Copy link
Member Author

till commented Nov 6, 2012

Opened another PR #110.

We should be down to like 6 or 7 (depending on my other PR) test failures.

@till
Copy link
Member Author

till commented Nov 6, 2012

@cweiske @saltybeagle Maybe you guys can give me an example of how I would convert this failing test case then?

@till
Copy link
Member Author

till commented Nov 7, 2012

Progress:

6 FAILED TESTS:
/Users/till/Documents/workspaces/Pyrus/tests/AtomicFileTransaction/AtomicFileTransactionClass/createOrOpenPath/createoropenpath.fail.fp.stream.empty.phpt
/Users/till/Documents/workspaces/Pyrus/tests/AtomicFileTransaction/TransactionClass/createOrOpenPath/createoropenpath.fail.fp.stream.empty.phpt
/Users/till/Documents/workspaces/Pyrus/tests/Registry/Pear1/getdependentpackages/getdependentpackages.basic.phpt
/Users/till/Documents/workspaces/Pyrus/tests/RemotePackage/invalidpackage.phpt
/Users/till/Documents/workspaces/Pyrus/tests/ScriptFrontend/Commands/build.phpt
/Users/till/Documents/workspaces/Pyrus/tests/ScriptFrontend/Commands/upgradeRegistry.phpt

@till
Copy link
Member Author

till commented Nov 7, 2012

4 tests left

AtomicFileTransaction related

  • AtomicFileTransaction/AtomicFileTransactionClass/createOrOpenPath/createoropenpath.fail.fp.stream.empty.phpt
  • AtomicFileTransaction/TransactionClass/createOrOpenPath/createoropenpath.fail.fp.stream.empty.phpt

Cannot figure this one out. The code is supposed to throw an exception because of the 'borked' resource, but it works here. Maybe a PHP 5.4 change?

Registry/Pear1/getdependentpackages/getdependentpackages.basic.phpt

Test Failure: "names"
 in /Users/till/Documents/workspaces/Pyrus/tests/Registry/AllRegistries/getdependentpackages/basic.template line 49
Expecting:
array (
  0 => 'pear.php.net/HooHa2',
  1 => 'pear2.php.net/HooHa',
  2 => 'pear2.php.net/HooHa2',
)
Received:
array (
  0 => 'pear.php.net/HooHa2',
)
===DONE===

RemotePackage/invalidpackage.phpt

Fails because the error contains a different message - no idea why.

till added a commit that referenced this issue Nov 8, 2012
 * stream_copy_stream() never returns false but 0 (when nothing was copied)
 * all credit to @saltybeagle (Brett Bieber)
saltybeagle added a commit that referenced this issue Nov 8, 2012
@till
Copy link
Member Author

till commented Nov 8, 2012

Alright, have these failures now (5.4.x):

tests/Registry/Pear1/getdependentpackages/getdependentpackages.basic.phpt
tests/RemotePackage/invalidpackage.phpt

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants