Unexpected 13 is out now! It adopts
unexpected-set, docs here: https://unexpected.js.org/assertions/Set/to-be-empty/
Release notes: https://unexpected.js.org/releases/#v13-0-0-2022-04-26-
Regarding the node core test runner. I agree with the bikeshedding potential, but OTOH, I think it's done pretty well actually. The only thing I find a bit weird and alternative is the TAP output. If the goal is to be minimalistic and just the first thing you'd use, before adding any additional tooling, why just not do something like a minimalistic version of the spec reporter from mocha (which pretty much seems to be the default thing in all test runners)
TAP out means that you have to use modules to make "pretty" output.
But with regards to the API, having a single method test, acting like it and describe, which fails on a throw or a rejected promise. And it is a requireable and not a global injected by a runner. It's exactly how I would want it :)
Only reason to use an external runner for me would be when you want coverage, but that's probably coming soon as well, as that is built into v8 now
But with regards to the API, having a single method test, acting like it and describe, which fails on a throw or a rejected promise. And it is a requireable and not a global injected by a runner. It's exactly how I would want it :)
Haha I was looking for my loved beforeEach 😂
Only reason to use an external runner for me would be when you want coverage, but that's probably coming soon as well, as that is built into v8 now
We use that already.
I know what you mean @papandreou - we need only to look to
assert. But I think the biggest problem with assert is that people wanted to keep changing it. It was broken to begin with, but I think the idea of having small and "good enough to get started" versions of things like test-runners and coverage built-in is valuable
@gustavnikolaj we just use this https://jestjs.io/docs/cli#--coverageproviderprovider with
v8 - maybe that wasn't what you meant.
You’re right. It has to come with willingness to make changes, otherwise it’s pointless. And it’s certainly easier with those things just being in userland. But I do have some deno/go envy about build-in testing, linting, etc. It would be nice if it does end going to shit
That was a pretty pathetic show to watch. It mangles all the color codes in the terminal etc. And no, it's not because I forget to use a tap-reporter.... And why would you select the tap protocol, and not include even just a basic reporter?! Then I need to have an external dependency anyway....
I'm trying to get a quick test up and running with unexpected-express:
// @ts-ignore
import unexpected from "unexpected";
// @ts-ignore
import unexpectedExpress from "unexpected-express";
import { app } from "./server";
const expect = unexpected.clone().use(unexpectedExpress);
(async () => {
await expect(app, "to yield exchange", {
request: {
url: "/post",
method: "POST",
headers: {
"content-type": "application/json",
},
body: {
title: "This is an attack",
content: "Pwnd!",
authorEmail: "hacker@hacker.org",
},
},
response: {
statusCode: 401,
body: "foo",
},
});
})();Getting an error I did certainly not expect:
$ ts-node src/server.test.ts
TypeError: stream.on is not a function
at eos (node:internal/streams/end-of-stream:166:10)
at IncomingMessage._destroy (node:_http_incoming:189:21)
at _destroy (node:internal/streams/destroy:72:23)
at IncomingMessage.destroy (node:internal/streams/destroy:64:5)
at endReadableNT (node:internal/streams/readable:1328:16)
at processTicksAndRejections (node:internal/process/task_queues:83:21)
at runNextTicks (node:internal/process/task_queues:65:3)
at processImmediate (node:internal/timers:437:9)I count out mocha to try and figure out where it came from. Am I holding it wrong?
It's been a while since I've been using unexpected-express, but I know it to be good to at least node v14. But we do fiddle around with some things on node core request and response objects.
Tests are not run on newer versions than 14
All errors seem related to request bodies and streams
Switched to node 14. Confirmed it works
Narrowed a problem (we might have more than one) down to this instance of the IncomingMessage class: https://github.com/unexpectedjs/unexpected-express/blob/master/lib/UnexpectedExpressMocker.js#L141-L145
Removing the custom destroy implementation in the below changes the stack trace
const req = new http.IncomingMessage({
destroy() {
requestDestroyed = true;
},
});With our destroy mock:
Uncaught TypeError: stream.on is not a function
at eos (node:internal/streams/end-of-stream:166:10)
at IncomingMessage._destroy (node:_http_incoming:189:21)
at _destroy (node:internal/streams/destroy:102:25)
at IncomingMessage.destroy (node:internal/streams/destroy:64:5)Without:
Uncaught TypeError: this.socket.destroy is not a function
at IncomingMessage._destroy (node:_http_incoming:188:17)
at _destroy (node:internal/streams/destroy:102:25)
at IncomingMessage.destroy (node:internal/streams/destroy:64:5)- Since v13 of node use of
this.connectionwas deprecated and it is just an alias forthis.socketnow. We usethis.connectionin many places in the UnexpectedExpressMocker file. - The destroy method on the original core module returns
thisfrom the method, and it seems that this is now being relied upon in core.
returning this doesn't alter the error message in the same way as removing our destroy method though.
Oh - this constructor doesn't work like a stream constructor - it just expects a socket. Which we don't pass it :D
but it breaks in new ways in node 18
Ci still running