In-fact, I can see more detailed error log thru console.log in JavaScript than what a single assertion statement display.
More information isn't always good. It can generate mountainloads of information which will become hard to sort through to find out whether a particular error was encountered.
You mentioned using Javascript, but the question is tagged for TDD in general, and I've responded as such. Your question seems to center around the benefit of assertions rather than their particular implementation, so I've kept the answer as it was written.
Whether it's a matter of exception throwing or custom message reading is irrelevant for your core question. What matters is that assertions are a standardized approach that allow other tools to cleanly report test outcomes (pass/fail) without needing developers to rifle through thousands of lines of logs.
Assertions, at their very core, are the combination of an if and a throw. Pretty much every assert can be rewritten to the format:
if ( !assertion )
throw new Exception(explanation);
Where assertion is a particular check, depending on which assert method you're calling, and explanation is a human readable message that explains exactly what went wrong in the assertion.
Whether it's an exception or a custom message is irrelevant, the point is that it is a standardized output method which clearly distinguishes a test success from a test failure. Assertion failures tend to behave as exceptions in the sense that they cause an early return, so the rest of the test isn't run anymore since it already failed.
Printing manual logs requires manual reading. Manual reading is laborious, annoying and not efficient. It may be perfectly acceptable if you have 5 tests, but most enterprise grade codebases have thousands if not tens of thousands of tests.
You may now be thinking that you could automatically search the manually created logs for specific codes that reveal that an error occured. Well, that's exactly what the assert framework does, but rather than looking for a specific text, it instead relies on a standardized output (exceptions/messages/codes/...) to indicate pass/fail results.
When you run your tests, you're initially really only interested in one question: is there a test failure somewhere?
At this point, you don't care about the output. You're not intending to read everything every time you run your tests. That'd be absolute madness. From personal experience, I run my current project's test suite about twice a day, and that's just under 10,000 tests. I am not going to read all of their output.
If a test fails, you are interested in more information, specifically which condition caused it to fail. This is where assertions come in again: every assert method cleanly writes a clear message that tells you exactly which condition caused it to throw an exception and intentionally cause a test failure, e.g.:
- Expected value to be "John", but found "Bob".
- Expected age to be at least 18, but is was 15
- Expected collection to contain "bla", but no such value was found
A properly written test is simple enough that you can immediately understand what assertion in your test caused the failure, which gives you a really good entry point to debug your code and find the source of the issue.
To summarize, assertions are beneficial because:
- They are easier to write and nicer to read than a manually crafted
if/throw construction
- They allow you to cleanly define the test conditions that decide test success/failure
- They generate simple and understandable error messages when they throw an exception
Doing this all yourself by writing manual logs is going to take more time developing it, it probably won't be as good as the existing assertions, and it's going to take massive amounts of time to even check the output of such logs on a daily basis.
