Files
zulip/frontend_tests/node_tests/zblueslip.js
Steve Howell e9c6653852 node tests: Always enforce blueslip warn/error/fatal.
We now require all of our unit tests to handle
blueslip errors for warn/error/fatal.  This
simplifies the zblueslip code to not have any
options passed in.

Most of the places changed here fell into two
categories:

    - We were just missing a random piece of
      setup data in a happy path test.

    - We were testing error handling in just
      a lazy way to ensure 100% coverage.  Often
      these error codepaths were fairly
      contrived.

The one place where we especially lazy was
the stream_data tests, and those are now
more thorough.
2020-02-07 14:15:44 -08:00

84 lines
3.3 KiB
JavaScript

/*
This test module actually tests our test code, particularly zblueslip, and
it is intended to demonstrate how to use zblueslip (as well as, of course,
verify that it works as advertised).
What is zblueslip?
The zblueslip test module behaves like blueslip at a very surface level,
and it allows you to test code that uses actual blueslip and add some
custom validation for checking that only particular errors and warnings are
thrown by our test modules.
The code we are testing lives here:
https://github.com/zulip/zulip/blob/master/frontend_tests/zjsunit/zblueslip.js
Read the following contents for an overview of how zblueslip works. Also take a
look at `node_tests/people_errors.js` for actual usage of this module.
*/
// The first thing we do to use zblueslip is patch our global namespace
// with zblueslip as follows. This call gives us our own instance of a
// zblueslip stub variable.
set_global('blueslip', global.make_zblueslip());
run_test('basics', () => {
// Let's create a sample piece of code to test:
function throw_an_error() {
blueslip.error('world');
}
// Let's add an error that we are expecting from the module.
// The function 'set_test_data' pushes the expected error message to the array
// of messages expected for that log type; here, 'error'.
blueslip.set_test_data('error', 'hello');
// Since the error 'world' is not being expected, blueslip will
// throw an error.
assert.throws(throw_an_error);
// zblueslip logs all the calls made to it, and they can be used in asserts like:
assert.equal(blueslip.get_test_logs('error').length, 1);
// Now, let's add our error to the list of expected errors.
blueslip.set_test_data('error', 'world');
// This time, blueslip will just log the error, which is
// being verified by the assert call on the length of the log.
// We can also check for which specific error was logged, but since
// our sample space is just 1 expected error, we are sure that
// only that error could have been logged, and others would raise
// an error, aborting the test.
throw_an_error();
assert.equal(blueslip.get_test_logs('error').length, 2);
// Let's clear the array of valid errors as well as the log. Now, all errors
// should be thrown directly by blueslip.
blueslip.clear_test_data();
assert.throws(throw_an_error);
assert.equal(blueslip.get_test_logs('error').length, 1);
blueslip.clear_test_data();
// Let's repeat the above procedue with warnings. Unlike errors,
// warnings shoudln't stop the code execution, and thus, the
// behaviour is slightly different.
function throw_a_warning() {
blueslip.warn('world');
}
// Populate one valid value, and test with an invalid value.
// This should throw an error, and we'll assert it was thrown by zblueslip.
blueslip.set_test_data('warn', 'hello');
assert.throws(throw_a_warning);
blueslip.clear_test_data();
// Now, let's add our warning to the list of expected warnings.
// This time, we shouldn't throw an error. However, to confirm that we
// indeed had logged a warning, we can check the length of the warning logs
blueslip.set_test_data('warn', 'world');
throw_a_warning();
assert.equal(blueslip.get_test_logs('warn').length, 1);
blueslip.clear_test_data();
});