Inlined unit tests
Posted: Fri Nov 10, 2006 10:48 pm
I wonder if that technique is used in complied languages like C...
What I mean is...instead of writing external tests, you actually write the tests as members of an object (stripped in production code) this way, you could also test private and protected members as well
Your objects ctor and dtor act as the setup and teardown functions...and this way...you avoid the worst part of writing unit tests...keeping your tests synchronized with the actual API...when I design...and first implement everything is extremely volatile...I change like lighting...keeping Agile so to speak
When the function signature or name, etc changes which again in my case is frequent...my unit tests have to change which is a PITA when your API changes as frequently as mine. This has one of two negative side effects.
1. Influences you to accept poorer quality API in order to reduce synchronizing tests with them
2. Influences you to give up on unit tests altogather because maintenance is a PITA
Now I know some are advocates of unit testing because it forces you to think about your design first...which admittedly it does...but it doesn't actually *force* you to do anything...just it helps to put some fore thought into an API before cranking out code, writing tests first then implementing...
The fact is...even with this fore thought my API still has a tendancy to change and keeping the windows open to rapidly keep my API/Tests synchronized is a double PITA.
Like writing API docs inline with the actual funciton makes life easier, so to would having your tests inlined as desciribed above...
Ignoring that in PHP it would add bloat - what is your opinion on this matter...can you see any down sides???
Cheers
What I mean is...instead of writing external tests, you actually write the tests as members of an object (stripped in production code) this way, you could also test private and protected members as well
Your objects ctor and dtor act as the setup and teardown functions...and this way...you avoid the worst part of writing unit tests...keeping your tests synchronized with the actual API...when I design...and first implement everything is extremely volatile...I change like lighting...keeping Agile so to speak
When the function signature or name, etc changes which again in my case is frequent...my unit tests have to change which is a PITA when your API changes as frequently as mine. This has one of two negative side effects.
1. Influences you to accept poorer quality API in order to reduce synchronizing tests with them
2. Influences you to give up on unit tests altogather because maintenance is a PITA
Now I know some are advocates of unit testing because it forces you to think about your design first...which admittedly it does...but it doesn't actually *force* you to do anything...just it helps to put some fore thought into an API before cranking out code, writing tests first then implementing...
The fact is...even with this fore thought my API still has a tendancy to change and keeping the windows open to rapidly keep my API/Tests synchronized is a double PITA.
Like writing API docs inline with the actual funciton makes life easier, so to would having your tests inlined as desciribed above...
Ignoring that in PHP it would add bloat - what is your opinion on this matter...can you see any down sides???
Cheers