Thanks for the translation, including your writing random tests.

The problem is you are not actually calling your random tests. You need to include it in your allTests array.

Change this:

    static var allTests = [
        ("decode", testExample)
    ]

To this:

    static var allTests = [
        ("Fixed Tests", testFixed)
        ("Random Tests", testRandom)
    ]

Note that I also changed the name from testExample() to testFixed() to fix that cosmetic problem.

Needs random tests in the full test suite.

It's good to tell people the input that resulted in the incorrect output, like this:

XCTAssertEqual(5, litres(11.8), "Incorrect result for hours: 11.8")

Or, in a random test:

let hours = Double.random(in: 0.1 ..< 12.0)
let expected = (insert math here)
XCTAssertEqual(expected, litres(hours), "Incorrect result for hours: \(hours)")

1. It would be nice tell the user the quantity and price that results in incorrect output. Instead of this:

        XCTAssertEqual(mango(quantity: q, price: p), (q-(q/3))*p)
   

Try this:

        XCTAssertEqual(mango(quantity: q, price: p), (q-(q/3))*p, "Incorrect output for quantity \(quantity) price: \(price)")

Same on the fixed tests.

Also (cosmetic issues):
2) get rid of the //TODO comments at the top of the tests.
3) Change testExample() to testFixed()

Thanks for the translation candidate.

Cosmetic issues found during my review:

1. Get rid of these comments at the start of the sample tests and full tests:
   // XCTest Spec Example:
   // TODO: replace with your own tests (TDD), these are just how-to examples to get you started

2. Change testExample() to testFixed() (both in sample test and full tests)

I normally like to give meaningful test failure output but I'm not sure if there's a better way to do it here given we're solving an infinite loop problem

Thanks for double checking. @Hobovsky just approved the translation!

Here's my Swift translation checklist, based on a moderator reviewing my stuff heavily:

1. Rename function to lower camel case
2. Include messaging in test asserts like this: XCTAssertEqual(sixToast(4), 2, "Incorrect answer for num = 4") (where num is the function parameter name)
3. Include tests for low, high, and edge cases
4. Change testExample to testSample
5. Include random tests
6. Shuffle random tests if possible
7. Change test names. Should not be “example”. Full tests should not be named “sample”
8. Remove TODO comments from tests
9. Make initial solution compilable without errors (adding “return 0” for example
10. If floating point, consider conversion to integers or use the XCTAssertEqual(converter(mpg: 36),12.74,accuracy: 0.01, "Incorrect answer for mpg: 36)")

Minor stuff you should do for this translation:

1. Rename function to lower camel case to conform to Swift programming best practices.

2. Remove the 2-lines of //TODO sample comments from the top of the sample tests and full tests.

Thank you for submitting a fix for the broken "Kata example twist" Swift tests.

The good news is it looks like you fixed the horribly broken tests.

The bad news is (based on the diffs) I'm concerned about the integrity of the Description, which is shared amongst all the languages. I've asked a moderator to take a close look at it. The diff is confusing when I look at it.

For reference, here's how to add swift-specific lines:

Add the value "codewars" to the array `websites` 1,000 times

One other minor nitpick is to get rid of the sample comments //TODO at the top.

Thanks for submitting a Swift translation for "do i get a bonus". I'm helping review them but I don't have privileges to approve/reject.

Sample test cases:
Get rid of the comment at the top (Example/TODO)

You need multiple sample test cases. All you currently are doing is assering that 1 == 1

Test cases:

Rename testExample() to testFixed()
Add a few more fixed tests
Add random tests where you randomly generate the salary and whether bonus is true

your function name bonus_time() should be renamed to bonusTime() to conform with Swift function naming practices.

In tests consider giving meaningful feedback by adding a third parameter. Here's one of mine from my "six toast" Swift translation:
XCTAssertEqual(sixToast(4), 2, "Incorrect answer for num = 4")
(where num is the function parameter name)

For reference, here's my "Swift translation checklist" that (usually) gets me past a moderator's reviews:

1. Rename function to lower camel case
2. Include messaging in test asserts like this: XCTAssertEqual(sixToast(4), 2, "Incorrect answer for num = 4") (where num is the function parameter name)
3. Include tests for low, high, and edge cases
4. Change testExample to testSample
5. Include random tests
6. Shuffle random tests if possible
7. Change test names. Should not be “example”. Full tests should not be named “sample”
8. Remove TODO comments from tests
9. Make initial solution compilable without errors (adding “return 0” for example
10. If floating point, consider conversion to integers or use the XCTAssertEqual(converter(mpg: 36),12.74,accuracy: 0.01, "Incorrect answer for mpg: 36)")

Here's updated tests from my fork. Feel free to incorporate in yours since you wrote the original translation and appear to still be active:

func testExample() {
    XCTAssertEqual(otherAngle(a:30, b:60), 90, "Incorrect result for a:30 b:60")
    XCTAssertEqual(otherAngle(a:60, b:60), 60, "Incorrect result for a:60 b:60")
    XCTAssertEqual(otherAngle(a:43, b:78), 59, "Incorrect result for a:43 b:78")
    XCTAssertEqual(otherAngle(a:10, b:20), 150, "Incorrect result for a:10 b:20")
}

func randomTest() {
    for _ in 1...100 {
      let a = Int.random(in:1...178)
      let degreesAvailableForB = 180 - a - 1;
      let b = Int.random(in:1...degreesAvailableForB)
      let c = 180-a-b
      
      XCTAssertEqual(otherAngle(a:a, b:b), c, "Incorrect result for a:\(a) b:\(b)")
    }
}

Consider the random tests:

      let a = Int.random(in:1...175)
      let b = Int.random(in:1...180) - a
      let c = 180-a-b

If the first random is 1, and the second random is 1, then angle b is 0 degrees.

By comparison, the C translation lets the first angle range from 1 through 178, leaving 2 degrees for the 2nd and third angle.

Updated translation based on feedback from Hobovsky (thanks):

1. Tests give "incorrect input for num XX" information for a failed test.
2. Random tests broken into two groups: guaranteeing random low and high tests.
3. Sample tests renamed to fixed tests for the full test suite.

My student Marco accidentally solved this by adding an int parameter which grabbed the correct result (18 or 0) off of the test suite parameter. Crazy!

Thank you for the feedback!

I agree that it's a duplicate of the retired kata. I was wondering why my searches failed to find a simple C<->F temp converter. It looks like the retired one also had "testing floats for equality" testcase issues. I'll have to figure out how to search retired katas. The "assert approx equal" mentioned there looks useful!

I don't agree that the existence of the 6 kyu "convert between many temperature scales" kata invalidates the need for a 8kyu C<->F kata (I saw that one before writing mine). C->F is a standard problem given to CS100 students in their first two weeks of class. But you wouldn't give that 6kyu version as a problem for new programmers!