
Cover your PHP legacy code with 1000 unit tests in just few lines of code - zavg
https://github.com/zavg/Asis
======
jonstjohn
This is a cool idea but seems fairly limited when you take into consideration
the state of the resources used in your application. For example, if I have a
method that checks the balance of an account, I may hit that method with an
account with a positive balance, make a payment, then hit the method again and
have a zero balance. The method might take an account instance and the same
account instance yields two different results.

I realize that this may be an issue with a poorly written method or un-
anticipated side effects, but with legacy code, that is often what you have to
deal with.

Cool stuff, though!

------
andybak
At first glance this appears vaguely similar to this for Django:
[https://django-test-
utils.readthedocs.org/en/latest/testmake...](https://django-test-
utils.readthedocs.org/en/latest/testmaker.html)

------
segmondy
Yeah, this will be great for a functional language. PHP functions tends to
have side effects and their results often rely on variables outside of the
function which means the tests will be wrong.

~~~
jtreminio
Wait, what?

Are you referring to something like globals?

~~~
segmondy
not just globals, but what could be in the database, or global variables get,
post, session variables. you don't test with your production database do you?

~~~
jtreminio
My unit tests are isolated. I don't unit test database connections.

------
jaredmcateer
Anyone know the minimum version of PHP this supports? I still have to support
code on 5.2.4 :( I'd like to try and implement this when I get a chance.

~~~
zavg
I think it should work on it, it doesn't use PHP 5.3+ specific features.

~~~
jaredmcateer
Actually looks like you're using some magic constants (e.g., __DIR__) and
namespacing.

One instance of namespacing I've found so far is line 118 in the
Common/InputDataProvider.php

~~~
zavg
Yes, I have just noticed. It will be really great if you will make pull
request of version which is compliant to you old version!

~~~
jaredmcateer
You got it!

------
saltvedt
This look really cool! :)

How does it handle that time has passed since the recording of the test?

~~~
michaelfeathers
Generally, with this sort of thing you regenerate before refactoring episodes.
Tools are okay for creating a temporary behavioral invariant.

------
waps
This is why unit tests suck. They are but a simple exercise in basic code
interpretation. A computer can easily do it.

What you want to test is the interface of your module to the rest of the
application and whether it satisfies the published contract, and preferably if
it handles weird cases correctly.

Those tests cannot be done by a tool.

~~~
lotsofcows
[http://en.wikipedia.org/wiki/Unit_testing](http://en.wikipedia.org/wiki/Unit_testing)

You're criticising unit test for things that unit tests don't do.

I hate apples. They don't taste like pears.

~~~
waps
Bleh. That definition of unit tests is so bland as to not differentiate
between any kind of testing. That definition explicitly states that having a
person (like QA?) go through the app and see what happens also constitutes
unit testing. And that's bullshit, manual testing is not unit testing. And
neither is testing an entire module at a time.

A useful discussion on the terminology problem can be found here:
[http://c2.com/cgi/wiki?StandardDefinitionOfUnitTest](http://c2.com/cgi/wiki?StandardDefinitionOfUnitTest)

Most definitions define unit testing as testing the "smallest piece of code
that can be tested in isolation". Then my criticism definitely applies.

And given my code reviews, it's obvious that the vast majority of programmers
see unit testing as testing every individual function/method in isolation.
This actually hides problems by increasing total source code (actual code and
the tests + "compromises" for testability) and locks down internal structure
of supposedly encapsulated logic. Both are very, very bad things.

