remove codeception

[ruskiyos]

Looking at our tests, they are ALL unit tests. There is really no point in loading in all of codeception module if we are using only simple assertions. phpunit weighs so much less and is not much different than codeception (since codeception just wraps phpunit)

[alexcoffee]

You're right and I'm ok with removing codeception. In reality though we don't have that many tests yet, do the gains justify the cost of converting?

[ruskiyos]

much of the classes would remain the same, except for $I would be switched to $this and some metadata comments would change. also adding a phpunit.xml file and we can additionally add just the AspectMock component if we ever need to mock it would probably ONLY take around 2 hours to convert current tests

[iampersistent]

Why not codeception? I don't quite understand what weight has to do with the decision.

[alexcoffee]

For us it doesn't make sense because we don't care about weight and we are used to codeception. But if we wanted to make it into a public library then pure phpunit would be the more common dependency.

[ruskiyos]

if I have a project that uses only phpunit, why should codeception be a required (dev) package.

[iampersistent]

@alexcoffee I don't think codeception is a deterrent to people using a library.

@ruskiyos This project is using codeception. :)

[iampersistent]

I don't care enough to die on this hill, but I don't see any value in changing it.

[alexcoffee]

lol I don't care enough to die on the hill either and I don't see the benefit in changing it for us. But I do see the value in "don't require more than you use".

[ruskiyos]

this is a public packagist repo, not a project lol. that's why I want to remove the dependency on codeception. if someone has codeception installed, they will automatically have phpunit, but not the other way around When I released our autopilot plugin to the world, there were some people who contributed but were not familiar with codeception. i think