Are all the existing tests supposed to pass? I cl...

# strikt

[Dan Rusu]

Are all the existing tests supposed to pass?

I cloned the repo and ran ArrayAssertions but am getting strange failures where it's complaining about differing strings that appear to be equal so I wonder if I'm running into some sort of character encoding issue:

▼ Expect that "▼ Expect that ['f', 'n', 'o', 'r', 'd']:
              |  ✗ array content equals ['d', 'i', 's', 'c', 'o', 'r', 'd']":
  ✗ is equal to "▼ Expect that ['f', 'n', 'o', 'r', 'd']:
                |  ✗ array content equals ['d', 'i', 's', 'c', 'o', 'r', 'd']"
          found "▼ Expect that ['f', 'n', 'o', 'r', 'd']:
                |  ✗ array content equals ['d', 'i', 's', 'c', 'o', 'r', 'd']"

The way the tests are written makes it very difficult (and frustrating) to deal with test failures because:
1. Double-clicking on a failed test in IntelliJ doesn't navigate to the failing test
2. Clicking the Rerun Failed Tests button makes it seem like they all pass because it doesn't actually rerun any tests
I don't have these issues when I use Strikt for testing my own project so I wonder if this is caused by using contexts instead of a separate test method per scenario

[christophsturm]

You could temporarily change that one assertion to an assertequals to get a diff view in idea and see the difference.

[christophsturm]

And I always click on the stack trace to get to the test methods.

[Dan Rusu]

Thanks, it looks like the very last line of the stack trace at the bottom navigates to the failure. It would be nice if navigation would work via the IDE as most other projects do. Attempting to fix a test and re-running failed tests also doesn't work as it incorrectly reports that everything passes because it doesn't actually re-run the failing test

[Dan Rusu]

It turns out that the test is failing due to the line separator. If I replace the expected triple-quoted multi-line string with a regular string containing a manual \r\n then the test passes but this doesn't feel like the correct solution.

I'm on Windows 11 with IntelliJ configured to use System-Dependent line separator. I tried changing this property and rebuilding the project but no dice.

[robfletcher]

odd., it should be working. I will try to take a look. I’m in the middle of moving to a new team and dealing with a major storm / flash flooding so apologies for not being responsive

[Dan Rusu]

Oh, wow, I hope you're all safe. No rush and thanks for looking into this.

I was hoping to add tests to this PR that I submitted but I wanted to have the existing tests passing before I enhanced any tests:
https://github.com/robfletcher/strikt/pull/278

Alternatively, feel free to merge that in if you don't mind the missing tests and then we can circle back once the pre-existing test issues get resolved.

[christophsturm]

In failgood I run ci also on a windows vm to find issues like that. I can submit a pr to add this to strikt.

[robfletcher]

oh yeah, that never even occurred to me. That would be great.

[christophsturm]

https://github.com/robfletcher/strikt/pull/279

[christophsturm]

I guess it will fail on windows 🙂

[christophsturm]

actually it does work on windows, so its probably a problem with your git config

[robfletcher]

I wonder if it’s not building clean and that test is failing because Dan is modifying that class

[robfletcher]

I think the best thing is if I merge it (the PR looks fine to me) and then figure out what’s wrong

[robfletcher]

weird, it works for me locally

[robfletcher]

and I'

[robfletcher]

I really should get round to cutting a release. I’ll try to do that this week.

[Dan Rusu]

I just performed these actions:
1. Synced my fork (https://github.com/daniel-rusu/strikt)
2. Deleted my local repo and re-cloned it
3. Ran ./gradlew clean build --no-build-cache without making any changes
And the tests fail. Running that inside the strikt-core module produces:

647 tests completed, 87 failed

> Task :strikt-core:test FAILED

due to the same line-separator issue of missing `

Running git config --list includes this line (which I haven't added manually):

core.autocrlf=true

[robfletcher]

huh, that’s strange. Let me try with --refresh-dependencies and see if I hit the same thing

[robfletcher]

works

[Dan Rusu]

This is interesting, if I modify site.gradle.kts to add the deprecated jcente repository and refresh gradle then the dependency issues go away:

repositories {
    mavenCentral()
    jcenter()
}

If I delete the jcenter() line and refresh again then the dependency issues come back. I vaguely remember seeing something about someone else encountering the same dependency issue with Strikt.

I wonder if there's some additional dependency resolution setup for your environment.

[robfletcher]

I don’t see anything in my ~/.gradle that I think would affect that

[christophsturm]

but it works on ci, that should check that it works without any special settings

[robfletcher]

right

[Dan Rusu]

Unfortunately, even if I fix the dependency issue with jcenter, the tests still end up failing after building without the gradle cache so the dependency doesn't seem to be the root cause

Unrelated to the tests, something seems suspect with the dependency since someone else also ran into the same orchid resolution issue (I'll try to find that reference)

[robfletcher]

yeah, I’m pretty sure I’ve seen it intermittently before

[robfletcher]

not sure it was specifically that dependency, but it was one of the Orchid components

[christophsturm]

does site:orchid even run as part of regular ci?

[robfletcher]

I think it will at least compile

[christophsturm]

ci runs ./gradlew build, and that works. if i run ./gradlew site:orchidBuild locally that fails for me too

[robfletcher]

Even with jcenter() added back I get a link error trying to run that target

[robfletcher]

seems like it’s a problem with not having execute permissions to /tmp

[robfletcher]

I guess I’ve never done orchidBuild on this laptop before