Tests can get messy. In this video, you'll do a little clean up to make your tests cleaner and understandable.
This is a companion discussion topic for the original entry at https://www.raywenderlich.com/3530-testing-in-ios/lessons/10
This is a companion discussion topic for the original entry at https://www.raywenderlich.com/3530-testing-in-ios/lessons/10
Hi Brian,
Good series. I’ll continue with the advanced stuff, but I wanted to point up an inconsistency in the course regarding the Clear function test that might confuse beginners.
In the Red-Green-Refactor lesson, you state (correctly) that there is no way to tell if the zero you get after a clear was part of the original setup of the calculator or if the clear() call actually worked. This justifies putting in a calculation, and then clearing it.
In the subsequent lesson, you then remove the calculation, saying that you must simplify the test code. But the original problem remains, that you could also have a zero if the clear function did absolutely nothing (check it). This is because the test setup calls the constructor, providing a 0.0 result initially.
You should probably at least enter a nonzero number so that result is nonzero, before you call the clear() operation. That way you have actually tested the clear() functionality independent of the initial constructor of the class.
Otherwise, good job. Keep up the good work!
Best regards,
Mike Mehr
iOS Developer
Mountain View, CA
2 Likes
I got a little confused with this lesson. At the beginning of the course you told us that tests needs to be independent from each other. I dont know if I got it right, but with the last refactoring of the test class, we made the testClear dependent of the testResult. It maybe a didatic technic, and you want to fix it later, but right now I’m confused.
By the way…
Awesome course!
Thank you!
All we actually did was remove code that code was already being tested in another test case. This didn’t create a dependency between the two tests. Meaning, testResult can still fail but testClear can still pass.
We want to avoid a situation where a failing result in testResult would automatically cause testClear to fail.
So we also removed it for two reasons: a) it was being tested in another test case so it wasn’t necessary. b) it didn’t contribute to the testing of the clear function.
I hope that helps!
That doesn’t seem right: with testClear as you wrote, the following method passes the test, which is wrong
func clear() {
}
I agree with the previous comments. What good is it to test the value after the clear() operation if you don’t know what it was beforehand? This seems like a faulty test to me.
In the previous video, I added the body to the clear method which sets the result to zero. It’s not an empty method stub unless of course, you skipped the challenge video.
As for the test being faulty - well, you could certainly add a value to the calc, and then run clear. That’s certainly a more thorough test.
@bdmoakley, there is still to much code in the test method, if you remove the call the clear() the test will continue to pass…
The problem with all the removed code is that if I go and delete the implementation of clear() the test will still be green. Which means that I can’t trust that test. And you need to have a test suit that you can trust.
Looking to remove the duplicate test in the code is good, but to validate clear you need to have a value to be cleared to really validate that clear does something, especially since the default value of the calculator is the same value as after a clear.
Thanks for the heads up - that’s the last thing you need is a test case that isn’t really testing. I’ll take a look and pass on your comment to the next updater. Thanks so much!