SortedArray icon indicating copy to clipboard operation
SortedArray copied to clipboard

Integrate property-based tests using SwiftCheck

Open ole opened this issue 8 years ago • 6 comments

ole avatar Jan 09 '18 20:01 ole

The added confidence provided by the generated tests is great, but I'm reluctant to merge this.

  • I don't like to have an external dependency just for the sake of the tests.
  • We'd have to drop SwiftPM support for Swift 3.1. (The Swift 3 build using Xcode 8.3 should still work, but it fails on Travis. Not sure why.)

ole avatar Jan 10 '18 14:01 ole

WAIT. There is a way. Gimme a couple of minutes. This can be done. Don't cut this PR yet

felix91gr avatar Apr 22 '18 04:04 felix91gr

They had this same issue at Quick: full explanation.

To quote ikesyo:

It's unfortunate, but most Swift package indexes list Quick as having a dependency: Nimble. This is not true, of course -- Quick isn't dependent upon Nimble, it simply uses Nimble as part of the test suite that tests Quick.

But this need of testing frameworks as testing dependencies (though not project dependencies) was satisfied under the PackageDescription v4 API

Basically you do this:

import PackageDescription

let package = Package(
    name: "FooBar",
    targets: [
        .target(name: "Foo", dependencies: []),
        .testTarget(name: "Bar", dependencies: ["Foo"]),
    ]
)

And so when testing, you get to download your favorite testing frameworks, be it SwiftCheck, Nimble, Spectre... But when building your module for non-testing purposes, you don't. Which is awesome <3

So there's that. Sorry for the intromission, but I like your project and SwiftCheck and I think SC was made precisely for Data Structures libraries. It'd be a shame to let this synergy go.

felix91gr avatar Apr 22 '18 04:04 felix91gr

Yeah, this is exactly what we’re doing in this PR: https://github.com/ole/SortedArray/pull/20/files#diff-37ca2dd15ca0f6b1b49e78db084ef5b9

I thought it was a shame to drop Swift 3 compatibility for such an internal change, though, but maybe it’s time.

ole avatar Apr 22 '18 07:04 ole

Ohh, I see.

I thought it was a shame to drop Swift 3 compatibility for such an internal change, though, but maybe it’s time.

I'd tend to agree.

If you want to continue supporting 3.1 though, you could use an #if swift(>3.1) directive to conditionally compile this part. Alternatively, you could put in the Readme up to which release you support 3.1 and then continue forward like that.

felix91gr avatar Apr 22 '18 14:04 felix91gr

If you want to continue supporting 3.1 though, you could use an #if swift(>3.1) directive to conditionally compile this part.

No, conditional compilation can't specify different tools versions for Package.swift as far as I know. We'd have to provide two versions of the package manifest (e.g. Package-swift3.swift and Package.swift), and users would have to rename it manually. That's not very elegant. (And possibly the Swift 3 version would then still compile and link the SwiftCheck sources; I don't remember if it was possible to specify specific source paths in the Swift 3 manifest format.)

ole avatar Apr 23 '18 13:04 ole