Because the target might not have been built correctly. The next time you make the project, it will attempt to rebuild the target. If the file had not been removed, make would have no way of knowing something went wrong. make can't know that the failure was coming from a test rather than the process that builds the target.
Whether or not this behavior is desirable in your case depends on the nature of the tests. If you plan on fixing the test so that it does not cause a Bus error, removing the target isn't a big deal. If you want to use the target for debugging later, you'll need to make a change to your make process.
One way to not delete targets is to use the .DELETE_ON_ERROR target.
Another might be:
$(tests): %: %.c
gcc -o $@ $(testflags) $<
-$@
Not tested, but the documentation indicates the target will not be removed:
When an error happens that make has not been told to ignore, it implies that the current target cannot be correctly remade, and neither can any other that depends on it either directly or indirectly. No further commands will be executed for these targets, since their preconditions have not been achieved.
and:
Usually when a command fails, if it has changed the target file at all, the file is corrupted and cannot be used—or at least it is not completely updated. Yet the file's time stamp says that it is now up to date, so the next time make runs, it will not try to update that file. The situation is just the same as when the command is killed by a signal; see Interrupts. So generally the right thing to do is to delete the target file if the command fails after beginning to change the file. make will do this if .DELETE_ON_ERROR appears as a target. This is almost always what you want make to do, but it is not historical practice; so for compatibility, you must explicitly request it.