-4

I'm new to TDD. That begin said, I'm trying to understand why would I have to use assertion library when there is console.log/print?

In-fact, I can see more detailed error log thru console.log in JavaScript than what a single assertion statement display. console.log helps me more than assertion library.

I do use Mocha for testing and Chai for assertion. I like Mocha for it's grouping features and Chai seems feel like a optional thing.

A similar question asked here https://stackoverflow.com/questions/29725571/what-is-assert-in-javascript but no one had provided answer to console.log question except the rest.

1
  • 5
    So that you don't have to read through all of the outputs of every test suite yourself?! Put it another way - what's the point of automated testing if it creates more manual work?
    – jonrsharpe
    Apr 12 '20 at 14:57
7

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.

16
  • I was doing tests one by one as I write code. I don't know how other people write their tests. As for me, It does not take much time to look at the output. I haven't experienced 10,000 test cases yet. I'm just a hobbyist and never wrote a single commercial code base for my life. It would be good if you can provide more context on how you doing the tests, whether you writing them one by one or just bulk etc.
    – sqlbie
    Apr 12 '20 at 16:36
  • @sqlbie: Most of the guideline simply doesn't apply on a sufficiently small scale like yours. Pure TDD expects that you write tests before you write code, which entails knowing the functional requirements of your codebase, which generally means someone who is not the developer analyzed the specs. That simply doesn't apply to a hobbyist with no professional experience. Writing tests as you go to check the code you just created is much more applicable to your scenario. Just realize that the further you go, the bigger your codebase (and thus testbase) becomes, and how much work your testing takes
    – Flater
    Apr 12 '20 at 16:50
  • How does Devs refactor the code in Pure TDD scenario if the whole code written after all test cases? Say, you got 100k size code base written after all test cases written then you start to run the test and the test return lot of errors, so you have to refactor the code which would take huge time and effort.
    – sqlbie
    Apr 12 '20 at 17:05
  • 1
    @sqlbie - to give you some more clarity about assertions; basically, we write tests as we go along, and we run all (or many of) the tests at once (ideally, this takes less then a second), because we fiddle with the shape and the structure of the code along the way, and we want to see if that fiddling had unintended side effects as soon as possible (e.g., if we broke something completely unrelated due to a broken implicit assumption, logic error, or unchecked coupling). Test libraries essentially use assertions to automate result reporting. 1/2 Apr 13 '20 at 20:48
  • 1
    @sqlbie - We also want to write tests in such a way as to express the intent of the test clearly, so that each test checks a very specific thing, so that, if it fails, we know immediately what was the intended usage (a test is basically an example), what failed, and why. Assertion libraries help us express that in code more clearly. As for how to do TDD & what interfaces are for, and how abstraction works in OOP: it will make more sense to you as you get more experienced, as these are all disciplines & techniques used essentially to keep accidental complexity of the codebase in check. 2/2 Apr 13 '20 at 20:50
5

Suppose you have written 200 testcases and each testcase prints about 10 lines of logging to the console. That is 2000 lines of logging to inspect to see if anything failed. And don't come back that a testcase will only print logging if it has a failure, because the code you are testing may also produce output of its own.

Assertions can help you in two ways

  1. They can terminate a testcase on the first sign of trouble, so that you don't try to slog on with incorrect data
  2. And more importantly, they integrate with reporting tools that can give you a nice overview which of the 200 tests failed and possibly even the 10 lines of console output that that particular testcase produced, so you don't have to search through 2000 lines to figure out what went wrong.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.