Forum Discussion
tristaanogre
13 years agoEsteemed Contributor
The problem with architecturing tests around exceptions is that you won't be able to easily distinguish an exception that is due to the test failure versus an exception due to a code environment problem. I tend to use exceptions only for trapping unexpected failures (syntax problems, windows that never appear that I'm expecting, etc) while, if I'm checking something as a "works" and "doesn't work" condition, boolean returns work best.
Just my $0.02 really, but I think a better design that provides a tighter control is to do something like
but hey, that's me.
Unfortunately, as mentioned, because of how "Runner.CallMethod" operates, I don't think you'll be able to do exactly what you're looking for. I could be wrong, but that's been my experience.
Just my $0.02 really, but I think a better design that provides a tighter control is to do something like
function Foo(TestString):boolean;
begin
try
if not condition raise('yada')
result := true;
except
result:=false;
end;
end;
but hey, that's me.
Unfortunately, as mentioned, because of how "Runner.CallMethod" operates, I don't think you'll be able to do exactly what you're looking for. I could be wrong, but that's been my experience.
Related Content
- 4 years ago
Recent Discussions
- 16 hours ago
- 23 hours ago
- 23 hours ago