node tests: Add more comments to general.js.

This commit is contained in:
Steve Howell
2020-12-01 12:38:14 +00:00
committed by Steve Howell
parent 52e9c4bc6a
commit 4efed2c975

View File

@@ -1,15 +1,25 @@
"use strict"; "use strict";
// This is a general tour of how to write node tests that
// may also give you some quick insight on how the Zulip
// browser app is constructed.
// The statements below are pretty typical for most node
// tests. The reason we need these helpers will hopefully
// become clear as you keep reading.
const {strict: assert} = require("assert"); const {strict: assert} = require("assert");
const {set_global, zrequire} = require("../zjsunit/namespace"); const {set_global, zrequire} = require("../zjsunit/namespace");
const {run_test} = require("../zjsunit/test"); const {run_test} = require("../zjsunit/test");
// This is a general tour of how to write node tests that // Let's start with testing
// may also give you some quick insight on how the Zulip
// browser app is constructed. Let's start with testing
// a function from util.js. // a function from util.js.
// //
// We will use our special zrequire helper to import the
// code from util. We use zrequire instead of require,
// because it has some magic to clear state when we move
// on to the next test.
//
// The most basic unit tests load up code, call functions, // The most basic unit tests load up code, call functions,
// and assert truths: // and assert truths:
@@ -61,12 +71,18 @@ const denmark_stream = {
// Some quick housekeeping: Let's clear page_params, which is a data // Some quick housekeeping: Let's clear page_params, which is a data
// structure that the server sends down to us when the app starts. We // structure that the server sends down to us when the app starts. We
// prefer to test with a clean slate. // prefer to test with a clean slate.
//
// We use both set_global and zrequire here for test isolation.
//
// We also introduce the run_test helper, which mostly just causes
// a line of output to go to the console. It does a little more than
// that, which we will see later.
set_global("page_params", {}); set_global("page_params", {});
zrequire("stream_data"); zrequire("stream_data");
run_test("stream_data", () => { run_test("verify stream_data persists stream color", () => {
assert.equal(stream_data.get_sub_by_name("Denmark"), undefined); assert.equal(stream_data.get_sub_by_name("Denmark"), undefined);
stream_data.add_sub(denmark_stream); stream_data.add_sub(denmark_stream);
const sub = stream_data.get_sub_by_name("Denmark"); const sub = stream_data.get_sub_by_name("Denmark");
@@ -325,6 +341,11 @@ run_test("add_user_event", () => {
to put some stub objects into the global namespace (as to put some stub objects into the global namespace (as
opposed to using the "real" code). opposed to using the "real" code).
This is where we see a little extra benefit from the
run_test wrapper. It passes us in an object that we
can use to override data, and that works within the
scope of the function.
*/ */
set_global("activity", {}); set_global("activity", {});