Skip to content

test: introduce tag functions to handle long strings in code

Rodrigo Muino Tomonari requested to merge github/fork/vsemozhetbyt/test-common-tags into master
Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

test

Multiline template literals in ES6 make long strings handling easier in code. However, there are many annoying nits that prevent this option from using in many cases: code block indentation adds unwanted spaces to these strings, leading and trailing backticks break alignment or add unwanted leading and trailing line breaks.

This PR proposes 4 helper functions to mitigate these difficulties:

  1. common.tagGlue() — joins a multiline template literal seamlessly, i.e. removes all literal line breaks and leading spaces (handy to code big text blobs not intended for human reading).
  2. common.tagUnwrap() — joins a multiline template literal with a space, i.e. replaces all literal line breaks and leading spaces with a space, then trims one leading and one trailing space (handy to code long readable text lines).
  3. common.tagLFy() — preserves line breaks as \n, but removes two framing line breaks and only auxiliary indents (handy to code multiline readable text, JavaScript metacode, HTML markup etc).
  4. common.tagCRLFy() — same as tagLFy(), but replaces all literal \n by \r\n (handy to code raw HTTP requests/responses).

You can see examples in the proposed doc fragments.

This PR also demonstrates the applying these functions to many test fragments.

All these functions leave interpolated variables untouched, only literal parts are processed. In most cases, these functions get multiline strings with leading and trailing line breaks: this allows to divide code noise (backticks etc) and pure data. These leading and trailing line breaks are stripped by the tag functions. This should be taken into account: if the result needs a line break in the very end, an additional line break should be added (beware, for example, HTTP raw code — see samples in the second commit).

I understand that this is a big PR and mostly based on personal taste. So see it as a strawman and feel free to reject without thorough explanations.

Though the diff seems huge, the changes are mostly trivial, concern multiline blocks formatting and are easy to skim.

Merge request reports