Java Assertions, in comparison/contrast to Unit Tests and Exceptions -
here's high-level, general question:
why 1 use assertions opposed unit tests , exception handling?
to clarify confusion , qualify concerns, i'll talk bit know of java assertions , background insofar pertinent line of questioning.
so, start, before week, didn't know java framework's assertions, nor function, absolutely admit i'm not getting whole picture. being said, have been professional in web development, data, , api development decade now, i'm not entirely naive.
from i've read, , discussions i've had, assertions used during development, (almost) turned off in production, , check post conditions , class invariant values; can , used other things, these 2 things seem main contemporary usage. built on top of java exceptions, subtype of error, , thrown when violated. when turned off, add no runtime overhead.
to me, however, seem superfluous, when considering exception handling techniques , unit testing practices. fail see circumstance assertion alert programmer bug or issue exception handling or unit testing not.
following line of thought, seem me create code clutter. if not meant run in production , act development aid, presence in production code bit of anti-pattern: have separate source folders tests , test resources, , write testable code, rather code strictly testing. whenever find myself writing code can test, alerts me poor design, , step , re-architect i'm doing code testable. seems me example of paradigm being violated. wherever assertion exists, replaced try/catch block, if/then/else appropriate exception being thrown, or set of unit tests - @ least, that's way seems me. having assertions in production code, not run during production, confusing. distracts purpose of code , code's doing. find test evaluate same condition assertion immensely more readable, since it'd contained in test named , documented exact scenario.
can others add insight train of thought? perhaps agree - add examples why or expound upon reasoning. again, maybe think i'm wrong - state why , provide examples reasoning, or provide counter-arguments way view things.
thanks all!
resources i've consulted, reference:
this topic opinions, add few thoughts have topic. not cover aspects can complement others' opinions.
sometimes use asserts express made assumptions when writing code. simple example: call method obtain value in general can null e.g. find user name in particular situation can't happen because e.g. in middle of registration. therefore skip "null check" in code want make clear whom ever read code afterwards (maybe me in 1 month :)) have considered option
user user = finduser(userid); assert user != null : "we in middle of registration" user.confirmemail(); clearly, can use simple comment so, not worse when comes cluttering of code.
second use-case is, mentioned, checking of invariants. "school example" situation implementing merge sort , during merge phase algorithm expects both subarrays want merge sorted (by previous steps).
clearly, implement unit tests check if sorting works well, can verify "end end" correctness. that's fine of situations, implementing it, find out 1 of tests failing. unfortunately, test uses "big input" , "simple" tests passing, impractical debug problem. merge class has no state , works recursion , local variables, can't introspect state outside unit tests. place can use asserts check internal invariants. , once invariant fails, stacktrace (so find out there problem in 4th level of recursion) , can add actual state of important local variables message can identify circumstances of error. asserts here since don't want "recheck" if subarrays sorted during production such checks can quite expensive.
once fix code, might tempted remove such code, can depend on situation. why write unit tests in first place? because if make refactoring, want sure if haven't break anything. , if expect might want refactor code , invariants made remain, might want keep them future. otherwise can delete them or don't use asserts @ , use temporal code find issue.
Comments
Post a Comment