Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Apr 27 07:08
    papandreou synchronize #845
  • Apr 27 07:08

    papandreou on update

    Add workaround to get the test … (compare)

  • Apr 26 21:37
    papandreou synchronize #784
  • Apr 26 21:37

    papandreou on camelCase

    Sketch out some basic tests Slow, naive implementation of t… Support camel case syntax withi… and 6 more (compare)

  • Apr 26 21:21

    papandreou on v13.0.0

    (compare)

  • Apr 26 21:21

    papandreou on master

    Add release notes 13.0.0 (compare)

  • Apr 26 21:10

    papandreou on update

    (compare)

  • Apr 26 21:10

    papandreou on master

    Update eslint-plugin-markdown t… Adjust configuration based on h… Merge pull request #820 from un… (compare)

  • Apr 26 21:10
    papandreou closed #820
  • Apr 26 21:03
    papandreou synchronize #820
  • Apr 26 21:03

    papandreou on update

    Adjust configuration based on h… (compare)

  • Apr 26 20:44
    papandreou synchronize #845
  • Apr 26 20:44

    papandreou on update

    Get most of the external tests … (compare)

  • Apr 26 19:43
    depfu[bot] synchronize #845
  • Apr 26 19:43

    depfu[bot] on update

    Update jest to version 27.4.5 (compare)

  • Apr 26 19:43
    papandreou commented #845
  • Apr 26 19:41

    papandreou on master

    Apply the jasmine patch for 4.x… (compare)

  • Apr 26 19:10

    papandreou on master

    Expect jasmine to exit with 3 w… (compare)

  • Apr 26 19:04

    papandreou on update

    (compare)

  • Apr 26 19:04
    papandreou closed #849
Andreas Lind
@papandreou
Unexpected 13 is out now! It adopts unexpected-set, docs here: https://unexpected.js.org/assertions/Set/to-be-empty/
Sune Simonsen
@sunesimonsen
👌🙌🔥
Gustav Nikolaj
@gustavnikolaj
🎉
Gustav Nikolaj
@gustavnikolaj
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
Sune Simonsen
@sunesimonsen

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.

Gustav Nikolaj
@gustavnikolaj

We use that already.

Through c8 or something else?

Andreas Lind
@papandreou
Let’s re-evaluate it in 5 years when it has completely stagnated because they can’t make breaking changes.
Gustav Nikolaj
@gustavnikolaj
beforeEach can be built by just wrapping test
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
Sune Simonsen
@sunesimonsen
@gustavnikolaj we just use this https://jestjs.io/docs/cli#--coverageproviderprovider with v8 - maybe that wasn't what you meant.
Gustav Nikolaj
@gustavnikolaj
arh, yeah, I suppose what I meant was that I hope they add that to the new internal test-runner somehow :)
Sune Simonsen
@sunesimonsen
Yes that would make sense.
Gustav Nikolaj
@gustavnikolaj
Would be nice if you didn't have to pull in half of npm to get basic test and coverage stuff. I'll probably still pull in unexpected, but if they had a simple assertion library with a functioning toEqual I could probably even use that from time to time ;)
Sune Simonsen
@sunesimonsen
@gustavnikolaj I tend to agree, if you could get something like deep equal and object match, that would be enough for most things.
Andreas Lind
@papandreou
As we know, deep equal and object match are just so difficult to get right. And then people’s test suites will start relying on the bugs in the implementation. And then you can’t ever fix it because it ships with the platform. See also: assert
Gustav Nikolaj
@gustavnikolaj
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
Andreas Lind
@papandreou
I assume you meant “doesn’t end going to shit”? 😜
Gustav Nikolaj
@gustavnikolaj
Yes 😅
Gustav Nikolaj
@gustavnikolaj
After having tried the built-in node:test runner I think I'll put down my sword and join your army @papandreou
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....
Peter Müller
@Munter
More career news: I handed in my resignation last week. I'm on the market from June 1st, though I might opt for a longer vacation if the right thing doesn't come along
Sune Simonsen
@sunesimonsen
wow
Andreas Lind
@papandreou
Wow, Peter!🎤💧
Peter Müller
@Munter

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?

Gustav Nikolaj
@gustavnikolaj
What node version are you on?
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
Gustav Nikolaj
@gustavnikolaj
Yep, tests pass on node 14, but breaks on 16.
All errors seem related to request bodies and streams
Peter Müller
@Munter
$ node -v
v16.1.0
Switched to node 14. Confirmed it works
Gustav Nikolaj
@gustavnikolaj

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.connection was deprecated and it is just an alias for this.socket now. We use this.connection in many places in the UnexpectedExpressMocker file.
  • The destroy method on the original core module returns this from 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
Gustav Nikolaj
@gustavnikolaj
Got a fix :)
but it breaks in new ways in node 18
Gustav Nikolaj
@gustavnikolaj
Ci still running
Gustav Nikolaj
@gustavnikolaj
passing tests on the node 16 pr, and here is another for node 18
unexpectedjs/unexpected-express#147
Peter Müller
@Munter
@gustavnikolaj awesome! I might just start testing my stuff then ;)
Gustav Nikolaj
@gustavnikolaj

unexpected-express v13.1.1 released with support for node.js 16 and 18.

I didn't remove the 10 and 12 versions yet (those are unmaintained now) but I didn't want to cut a major. Sorry, lazy me.

Andreas Lind
@papandreou
:muscle:
Gustav Nikolaj
@gustavnikolaj
Node 18.1 brought some improvements to the built-in test runner. It now doesn't mangle ascii colors in the output... And it has a --test flag on the node binary that works like mocha in recursive mode