Access of the functions and fixtures load

[sanis]

You should use protected functions instead of using private methods. I have made some modifications on the base of your ApiTestCase, but I can't reuse private methods.

Also I have made quick fix for fixtures. Sometimes I have timestamps in the wrong order (especially after updating fixtures), so they won't be loaded in the right order during the tests. Solution here was to order them by name and load in that order.

[lchrusciel]

Thanks for contributing.

Sorting fixtures by name have some sense, but I'm not sure if it is expected behaviour for all of the cases. loadFixturesFromDirectory is protected so it shouldn't be problem to customize logic in your project. It could be merged, but in separate PR. Can you split them?

Second part of your PR, is changing access to all methods to protected. Going further with your commit title, you could say, that all private methods are bad. Is it true? Doing open-source we have to be aware that we have to maintain this code. Each public or protected method can cause a BC break. Same with the final methods. Final classes and private methods should be used wherever it is possible. I'm not an expert, so you don't have to trust me, but here you have some presentation about that. This slide is a pretty important one.

I'm ok with making some of private methods protected, if there is real benefit for that. I'm also pretty sure, that there is no point in making all of them available(cuz protected methods are a part of API too).

[sanis]

loadFixturesFromDirectory itself is protected which is really good, but the problem here is that it uses private getFixtureRealPath which cannot be accessed from the child of class. That makes things complicated because I would have to rewrite getFixtureRealPath and assertSourceExists to my extended class to have it working in the similar way it works now just for sorting fixtures by name. There are two ways to solve the problem, making them private or just move fixtures finder generation to another protected method. Maybe second solution would make more sense after all. Maybe not all methods should be protected and you are right here. But I guess assertions like assertJsonResponseContent or assertXmlResponseContent or any others should be reusable, because they are pretty useful methods. :)

Talking about the fixtures there was an issue I faced. I was creating fixtures by appending number in the front to get them loaded in the right way during the fixtures load via command. It was working fine from the console, but after I have added loadFixturesFromDirectory from ApiTestCase I got them in the wrong order and I couldn't make relations between entities because they were loaded not in the right order. I guess problem here was that originally AliceBundle orders fixtures by the name, not the timestamps like Symfony finder does by default, so I would suggest to reuse that behaviour, because every update in fixtures makes them break in my case...

I will try to split both changes I have described into different PR and make it little bit in the nicer way. ;)