News for hackers. Stuff that matters.
Re:The Design and Use of QuickCheck by joshlemer on Monday June 12, 2017 @08:05PM (#14542113)
I've done a fair bit of testing with ScalaCheck. I do think it's useful to define your "generators" for your domain model(s), because without them, unit tests can end up being mostly data creation code. With your generators out in their own (testing) package, and named appropriately, you can get quite a bit of mileage out of them, even if you don't take advantage of the property-based testing framework beyond that. Something like..

    object Generators {

      val commentsGen: Gen[Comment] = ???
      val userWithTwoCommentsGen: Gen[User] = Gen.listOfN(2)(commentsGen).map(comments => new User(comments))

      val userWithNoCommentsGen: Gen[User] = Gen.const(new User(List.empty)
    
      val userGen: Gen[User] = Gen.listOf(comments).map(comments => new User(comments))
    }
And then your test code can get right to the point so to speak

    "Users with comments" should "karma equal to the sum of their posts" in {
      val users = Generators.userGen.take(10).foreach(u =>
        u.karma should be (u.comments.map(_.points).sum)
      )
    }
Re:The Design and Use of QuickCheck by thijsvandien on Monday June 12, 2017 @11:41PM (#14542728)
It looks like what you really needed is a fixture factory.
Re:The Design and Use of QuickCheck by estsauver on Tuesday June 13, 2017 @04:57AM (#14543627)
In a lot of ways, generators are like a cousin of factories. Fixtures are usually static though, and so they don't help you explore the problem space in the same way as generators do.
Re:The Design and Use of QuickCheck by anentropic on Tuesday June 13, 2017 @11:55AM (#14545741)
sounds like https://factoryboy.readthedocs.io/en/latest/ (for Python, based on a Ruby lib)

I never thought about the connection of that with Quickcheck