Wow, actually using the specified and installed PHPUnit 4.1.6 version breaks the tests...
Looks like "composer.json" and "composer.lock" files need to be updated to phpUnit 4.6.6

I'm going to suggest that this could be closed. These fixes (and the necessary phpunit changes) are included in #6884 so when that is merged it will eventually get merged from staging to 3.5-dev.

There's some stuff in the form tests using deprecated PHPUnit features (deprecated at 4.2) which cause test failures because of the deprecation notices (though if it's all passing on 4.6 now I wonder what changed). Or maybe the CMS doesn't have the same assertions as the Framework's using anymore. Who knows.

Maybe those deprecated PHPUnit features are in the tests that are skipped (or trigger the test to be skipped).

It's definitely passing with PHPUnit 4.6.6 in the #6884 PR. No Idea what changed. All I have learned is the current tests were running against the Travis installed version of PHPunit rather than the version installed by the composer files. I believe the Travis PHPUnit version might be 4.5.

Closing this as tests currently fail.
It can always reopened or just create a new PR when you figured out a way to solve it

@Bakual Sounds good, as I suggested this could be closed. I know how to fix the issue, the fix is include in #6884 (change phpunit to 4.6.6 in the composer files). It's a question of fixing it now in the 3.5-dev branch or waiting for #6884 to be merged into the staging branch and the eventual merge from staging to 3.5-dev.

I'm good with either choice, I guess someone with commit rights should decide which direction to go; Wait for #6884 or Fix in 3.5-dev now.

@photodude

eventual merge from staging to 3.5-dev.

staging will allways merge into 3.5-dev. 3.5-dev contains only the new features that should not get into a new minor release if #6884 gets in than it gets also into 3.5-dev.

Thanks