Get rid of `testify` dependency

[mlange-42]

Arche has no dependencies, except testify for unit tests. Would be great to get rid of them for normal module users.

Maybe go_test.mod is an option? See https://dev.to/wallyqs/introducing-gotest-mod-18a1

[emar-kar]

Hello there. I ran into your project a while ago and I would like to lend a hand of assistance if you don't mind. I'm currently looking through the code and tests. Regarding the current issue I can see this:

% go test -modfile=go_test.mod ./...
go: -modfile cannot be used in workspace mode

Do you want to remove testify assertions and replace them with what is offered by the standard library?

[mlange-42]

Hi @emar-kar, thanks for coming here and offering assistance!

Actually I was looking for a solution like modfile, which I was not aware of. Or like test/dev dependencies as in Python or Rust. Too bad that this won't world in workspace mode.

I think replacing all the assertions with 3-or-more-lines conditionals is not really worth the effort, nor the resulting code bloat.

So maybe there is a way to get rid of workspace mode? The sub-modules are not actually meant for users, they are just benchmarks and doc-tests for the user guide. So maybe they could be teated without a workspace at the top level, somehow?

[emar-kar]

Actually I was looking for a solution like modfile

I will investigate the options. Hope it is not something new and ppl already have discussed it somewhere in the depths of the go workspaces discussions.

I think replacing all the assertions with 3-or-more-lines conditionals is not really worth the effort, nor the resulting code bloat.

Either way is to write same code inside the project to cover the same usage of testify, which is not really worth it.

So maybe there is a way to get rid of workspace mode?

Tbh with you, I was thinking go.work was more about local development. Maybe I'm missing it, since I was not using it a lot. I'll look into an option to move benchmarks and doc-tests to a sub package in addition to more digging into the workspaces.

[emar-kar]

Hello again, after digging a little bit more into the question. The solution with -modfile requires all test to be at same folder:

• Make a test folder
• Include the tests with test dependencies in the test folder.

Since it is not an option, because tests requires a lot of internal logic of the package being available, creating additional test mod file is pointless. I checked it locally, and as soon as I move testify to the external dependency half of the project test files start to glow "red". If you want the project to have 0 dependencies, then it requires some more code adding to replace testify. It's clearly design decision. But if you want to do so, I can update tests.

P.S. After reading some articles, the common practise turned to be to store go.work files locally for development. It's again more about personal approach and recommendation, not a must have thing.

[mlange-42]

@emar-kar Thank you for researching and sharing it here! Yeah, there are definitely tests that are not possible with only the public interface accessible, so this is indeed not an option.

Regarding the PS, I thin this would still require the test folder, right?

[emar-kar]

Regarding the PS, I thin this would still require the test folder, right?

No-no, it was just what I noticed during the research. Since the first thing I did, was digging into the workspace mode. There are a lot of discussions about how to use it. And more often ppl advise to store go.work locally. I mentioned it since the first comment was with a sample:

% go test -modfile=go_test.mod ./...
go: -modfile cannot be used in workspace mode

But again, it is not something standard, just a design thingy.

[mlange-42]

Sowhat would be the effect of removing go.work? Not shure why I added it, I think something about the nested modules was not working.