Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign uptest(common): increase test coverage #309
Comments
|
@petermetz what is the reason to use tape/tap instead of common used jest? Looks like tape does not support from the box a lot of required functionality (beforeEach/spies/flexible matchers, etc). |
|
@petermetz I'm trying to do the task with the documentation I found on github and also based on the tests that have already been created, everything ok? |
Test Anything Protocol and in general to have tests and a testing framework that is simple and lightweight even if some of the cool features are missing. Does Jest support TAP? P.S.: The reason we have both tap and tape is because we are in the middle of a slow, gradual migration from tap to tape because only tape supports running tests in browsers. |
@eLeontev are aligned and not working on the same thing in parallel. ;-) |
|
I managed to create some unit tests, but I have a problem to test the Logger, since its methods return void. I was able to instantiate the class to call the method and see the log appear, but not pass the test yet. Any tips on how to use the |
@gabrielsoaresm94 Awesome, thank you for all your efforts so far! Based on what's described on the above link, this is just made up pseudo-ish code I can imagine being a workable solution blueprint. Let me know if this is good enough guidance! logger.test.ts / import dependencies...
test("logger writes to stdout", async(t: Test) => {
const log = LoggerProvider.getOrCreate({ level: "TRACE", label: "logger-test" });
/ generate random UUID v4 to guarantee we don't mistake something else as the marker
const marker = uuidv4();
/ hook up to the stdout data stream and wrap it in a promise that can be awaited
/ for when the marker does appear on stdout (which would be a passing test)
/ or when it times out (which would mean the test is failing).
/ Certain issues could happen here if the stream is chunking data and then you never
/ actually get the complete marker string at once but instead different parts of it
/ but I did not consider this because the uuid is only a few dozen bytes when stored as a hex string
/ so I'm pretty confident it wouldn't get chunked (probably not impossible either though so
/ if you are paranoid about that happening (which would make the test flaky) then you can
/ bake in some stream data aggregation instead where you collect and continually append
/ the incoming data chunks and test for marker presence in the aggregate variable not the chunk
/ that is provided in the 'data' event handler callback.
const promise = new Promise(resolve, reject) => {
const timerId = setTimeout() => reject(new Error('Timed out waiting for marker to appear on stdout');
process.stdout.on('data', (data: Buffer) => {
if (data.toString('utf-8').includes(marker) {
clearInterval(timerId);
resolve(marker);
}
});
});
/ send the log now that we have hooked into the stream waiting for the marker to appear
log.info(marker);
/ wait for the marker to appear on stdout OR crash with timeout if it never comes
await promise;
});
/ rinse and repeat for stderr
test("logger writes to stderr", ...) |
Description
As a community member of Cactus I want to feel good about using software that has good test coverage so that I can sleep a little bit better (not much because severe bugs can still lurk in codebases with 100% test coverage, but nevertheless...)
Currently if you run the test command for the common package (see below) then you get a coverage report is is mostly in the red. The idea for this issue is to turn that green.
Execute the tests of the common package
npx tap --jobs=1 --timeout=60 "packages/cactus-common/src/test/typescript/{unit,integration}/"The report at the end of the test execution:
Acceptance Criteria
All files) is all green meaning that it's above threshold (I think the limit for green is 85% but not a 100% sure on that)tapelibrary (nottap)cc: @jonathan-m-hamilton