Make CLI explict and add unit tests

tayloraswift / swift-noise

Generate and compose commonly-used procedural noises and distributions, in pure Swift

https://swiftinit.org/docs/swift-noise/noise

Apache License 2.0

116 stars 11 forks source link

Make CLI explict and add unit tests #17

Closed heckj closed 3 months ago

heckj commented 3 months ago

What had been noise-tests is now generate-noise, with code moved to its own directory under Sources, and output generated in the examples directory at the root of the project. A bit has been added to the README to explain how to invoke it and regenerate the noise.
NoiseTests continues to exist, but now as an explicit swift testTarget (that is, unit test), with a stub placeholder test. I saw there were array out of bounds issues reported for the project, so I thought to capture those in a unit test and resolve them.

tayloraswift commented 3 months ago

two unrelated comments:

what are your thoughts on adopting the new swift-testing framework?
i’m not seeing any changes to the Noise module. was #11 user error?

heckj commented 3 months ago

No qualms about reaching for swift-testing, it looks like a nice setup, but I was under the impression it wasn't really ready for use until Swift 6 hits the streets, so I've been waiting myself. Hopefully next week will show us the path they're aiming for there.

I haven't made any changes to Noise - this PR was all just setup to allow me to do so. When I looked through the open issues, both #11 and #3 appear to be reporting the same problem, and when i followed the details on #11, the author had worked around the issue in his own code, but other than seeing that he'd done something with his own fork, I didn't explore deeply. So I don't think it's user-error, and likely is a bug - I was going to put the content from #11 into an issue, and then dig on it, seeing what he did to work around it, to propose a fix. This was a "keep it working exactly as is, just reconfigure things a bit" PR to prep for that.

tayloraswift commented 3 months ago

there is a little bit of friction when using swift-testing with 5.10 but i am already using it in swift-json and the toolchain requirement doesn’t seem to be a hard requirement.

writing the tests against swift-testing means we won’t have to rewrite all the tests against a different framework in a few months time, which i imagine would involve much more effort than dealing with whatever breakages happen between swift-testing 0.9 and 1.0. plus, we can help out @grynspan and give him feedback from using the library in a popular, real-world project. WDYT?

heckj commented 3 months ago

Works for me - I'm game. I'm doing all my development in Xcode, which may present more of a challenge, but lets give it a shot. Worst case, I'll run all the tests from the CLI

tayloraswift commented 3 months ago

it just occurred to me that we should put the swift-testing-dependent tests in a sub-package, similar to the benchmarks, so we don’t conflict with anyone’s macros.

heckj commented 3 months ago

I understand your concern re: putting swift-testing in a subproject, but to me that drops the value of doing it all quite a lot. My goal was to have a fast path for "swift test" to replicate an issue, after which fixes could be quickly verified. I'm working from Xcode, so the test/build is pretty tightly linked, and working across projects With Xcode is a huge limitation - you basically can't have both open and functional at once, due to quirks of how they're handling dependencies.