ircdocs / parser-tests Goto Github PK

For example:

@ : blah blah blah blah

This is highly unusual, but message parsers shouldn't break when encountering it, for safety. Add some message splitting tests around it. Don't have message joining tests with these because they are fundamentally weird and dodgy.

Hi,

The last version released on PyPI was on 2019-01-04, so it's lagging on the git repo, and misses some bug fixes, like 1eea408

Could you publish a new release?

Thanks!

Both(?) of these seem to fail the tests right now, I should fix the libs and/or tests so they no longer fail.

I've done similar in the past where I've used a JSON Schema to provide a full schema for other files to be used during CI. This would give us a few benefits:

• As documentation for the format of each file, can also contain description of the format.
• Can be used to test that the test files are correct during any changes in CI. This will prevent any unintentional breakage cause by PRs.

As an example (schemas/userhost-split.yaml):

type: object
properties:
  tests:
    type: array
    items:
      '$ref': '#!/definitions/test'

definitions:
  test:
    type: object
    properties:
      source:
        type: string
        description: source is the usthost
      atoms:
        type: object
        properties:
          nick:
            type: string
          user:
            type: string
          host:
            type: string
    required: [source, atoms]

I've seen in the wild servers send host mask components in the incorrect order. We should include a test to ensure that the support in wrong order is correct.

class NickTests: XCTestCase {
  // ...
 
  func testNickInitializationFromHostmaskWithWrongOrder() {
    let nick = Nick(hostmask: "kyle@hostname!ident")
 
    XCTAssertEqual(nick.nickname, "kyle")
    XCTAssertEqual(nick.ident, "ident")
    XCTAssertEqual(nick.hostname, "hostname!ident")
  }
}

It's fairly broken right now, fix up how girc acts and as such fix up the script

Add failing tests with ' ' in the hostname to replicate that insp failing issue where they allowed spaces on hostnames.

Add to the comment on the file that clients should do NO HOSTNAME VALIDATION AT ALL and that it's 100% for servers to validate hostnames they get when they look up hostnames on incoming IPs.

Comparing nicknames, channel names etc in various case mappings could be introduced into this test suite.

class CaseMappingTests: XCTestCase {
  func testRFC1459EqualCompare() {
    let casemap = CaseMapping.rfc1459

    XCTAssertEqual(casemap.compare("hello{}|", "HELLO[]\\"), .orderedSame)
  }

  func testRFC1459Compare() {
    let casemap = CaseMapping.rfc1459

    XCTAssertEqual(casemap.compare("hello{}|1", "HELLO[]\\2"), .orderedAscending)
  }

/// etc ...
}

If we don't already, we should have tests to ensure that a tags line like this: @=53;+=ghfd doesn't result in empty tag names / a tag name that's just the c2c tag prefix. If we don't already, and if tag names must follow a specific structure / set of characters, we can add a test ensuring that too perhaps (either failing or just throwing that tag away, not sure which'd be more appropriate).

Useful for testers and for people trying to work out what on earth the exact tests are testing.

Keys "name" and "description" respectively (obviously).

I’ve always sorta ignored it as unsupported but if servers are sending values escaped that way (esp for spaces etc) it makes sense to have consistent implementations of it and all.

note to self: don’t mandate converting all utf-8 chars to the escaped forms, I could def see servers just using the encoding opportunistically for mostly stuff like e.g. space that’s not possible to represent b/c protocol limitations and junk, e.g. https://github.com/inspircd/inspircd/blob/6cfabb0/src/server.cpp#L176-L182

We have an extra test that handles this case, but we should have a proper short test that does just this as well.

For example, if ascii was used casemapping then FOO!*@* should match [email protected], etc. Perhaps we would need to introduce a 'casemapping' option. All of the tests appear to be all lowercase.

For instance, this:

  - input: ":services.esper.net MODE #foo-bar +o foobar  "
    atoms:
      source: "services.esper.net"
      verb: "MODE"
      params:
        - "#foo-bar"
        - "+o"
        - "foobar"
- ""

This case is very dodgy and handled very strangely by various software. Look at it more closely, see what software does today and how it tends to be handled, update Modern with what we decide.

08:31:11 < SaberUK> 1459 says:
08:31:11 < SaberUK> "all parameters are separated by one (or more) ASCII space character(s) (0x20)."
08:31:11 < SaberUK> "<middle>   ::= <Any *non-empty* sequence of octets not including SPACE or NUL or CR or LF, the first of which may not be ':'>"

This is a bit of a weird one, because it's fundamentally invalid and I'm not sure how you would handle that in the YAML -- empty verb key perhaps, and let it fail somewhere else in the stack?

Example (broken) input: :foo.

This raises a (cryptic) exception in goshuirc 0.4.0's RFC1459Message, so I think it may be important to test for:

goshuirc-irc/girc/ircreactor/envelope.py in from_message(cls, message)
    104             s = s[1:]
    105 
--> 106         verb = s[0].upper()
    107         original_params = s[1:]
    108         params = []

IndexError: list index out of range

Similar in nature to #12, which is for blank tag/source.

Message Tags can have a variety of escaped characters in them. The escaping isn't overly hard, but it can be an easy thing to get wrong, it'd be nice to have known test vectors for how this is supposed to work.

Sorry if these exist already and I missed them!