Re: Assertions
On Thu, Oct 17, 2013 at 7:03 PM, J David <[email protected]> wrote:
> All three cause unexpected behavior if the asserted condition is not
> true and assertions are disabled because the condition was not
> evaluated.
>
> In all three of those examples, the behavior you want is easily
> obtained by throwing an exception.
>
> In fact, what some people might do in those situations is:
>
> assert($myObject->internalState == OBJECT_STATE_VALID, "internal
> object state not valid");
> if ($myObject->internalState != OBJECT_STATE_VALID)
> throw FMLException("internal object state not valid");
>
> (In this case, you would probably do the PHPUnit stuff with assertions
> disabled.)
>
> Assertions are a debugging/development check designed to facilitate
> proof of correctness. They are not present or used in production
> code. There is no danger that a failed assertion will ever cause a
> production app to abort. They serve one purpose, which is to bring
> things to a screeching halt when somethat that should never, ever
> happen has happened. And their value comes *because* they are
> independent of methods used to handle potentially-recoverable errors.
>
Sorry, I still don't understand what you're trying to say. Ignoring my last
example, both PHPUnit and a "debug page" from the framework are clearly for
debugging/development. Both examples just take the failed assertion and
present it in a more appropriate form.
I am most certain that you do *NOT* want to abort the whole unit test run
because of an assertion failure in one single test. Tests are supposed to
continue running even if individual ones fail. There is nothing inherently
different between a test that failed because of an assertion and a test
that failed because it threw an unexpected exception or returned a wrong
value. In either case you want to see a test failure and continue to run.
Just imagine how terrible it would be if the PHP test suite would stop
running on the first test failure (of 12000 tests).
Similarly, showing a friendly debugging page when an assertion fails does
not seem to go against your idea of assertions. It just changes the
presentation form to simplify debugging the cause by specifying additional
information that is known to the framework (but not to the assertion
itself).
> Why do we need a new way to throw an exception?
>
> Why do we need to mess up another tool that has a different purpose to do
> it?
>
> What's wrong with writing the three-line function one time to get the
> behavior you want?
>
Those questions have a very simple answer: You can't disable code throwing
exceptions ;) Assertions can be disabled.
Nikita
Thread (36 messages)