swift icon indicating copy to clipboard operation
swift copied to clipboard

Don't use Module.function in tests

Open alexito4 opened this issue 5 years ago • 2 comments

There are some exercises where the test look like this:

     XCTAssertEqual(0, SumOfMultiples.toLimit(1, inMultiples: [3, 5]))

this confuse the students as SumOfMultiples.toLimit looks like a static function but can also be a free function scoped into the module. Some students have showed confusion as to why they needed to create a class for a simple exercise that needed no state. Although knowing about free functions, static/class methods and modules is interesting, I think it's desired it should be explained at it's own pace and not as a side effect of how a test is written.

alexito4 avatar Apr 28 '19 17:04 alexito4

This comes down to preference. I was also surprised when I learned that types can overload their module name. Initially most exercises did require a static function because that was my preference. I guess we could put in a note saying hey you can use a free function here?

masters3d avatar Apr 28 '19 17:04 masters3d

Yes I agree is question of preference, but I wonder what is the intended solution that the test imply? Do we want students to make a class with a static function?

Otherwise IMO we should just drop the module from the tests.

This tests makes it more clear:

    func testFlattenIntegerArray() {
        let result: [Int] = flattenArray([1, [2, 3, 4, 5, 6, 7], 8])
        XCTAssertEqual([1, 2, 3, 4, 5, 6, 7, 8], result)
    }

It seems to me that in the others is just done to have a better function name. But I would argue that the function name can be easily improved: SumOfMultiples.toLimit(_:, inMultiples:) -> sumOfMultiples(limit:,inMultiples:.

alexito4 avatar Apr 28 '19 18:04 alexito4