یک پردیس

In this post, I am going to present a quick summary of what I caught after reading the nice article from Michael May. This summary merely reflects my interpretation and, as always with other summaries, I highly recommend you read the original article if you have time.

Goal: Learn how to START to apply testing techniques when you have a pre-existing code base which has no test.

1. Start with the compiler settings. The compiler is the first place that you might go in testing an app that has no tests. In case you doubt this step, bear i mind that compilers assert certain things that you assume about your code, and we can call that a test.

2. Turn all warning messages on. Try to understand what is going on, and try to fix them. Actually, you may learn that the assumptions of the programmer and the compiler vary. That's where you should fix the issue.

3. Convert warnings to errors. For instance, in Objective-C, turn implicit signedness conversion on, and you may get some errors. If you know what the program is about, you will be able to fix those issues. [Not from the originl author: in learning, there is a notion called desirable difficulties you should better read about if you are a studyholic (, or you are not.)[Wow, it's amazing how psychology, software engineering, and pedagogy meet.]].

4. Try to do some basic refactoring for collections and arrays. Make the names clearer and make data types more specific if possible. We are not trying to change code; we are letting the compiler reassure us that we're making good assumptions.

5. Mutability is not a desirable attribute; as a standard offering. Try to wrap highly mutable stuff up into more controllable ones. Then we would be able to proxy the attribute of the access to them. You can get the compiler to tell you where a suspicious object is being mutated, and avoid undesirable ones.

6. Now, it's the proper time to extract the code and break it up into pieces that would properly belong in different places. First, we should extract bits of code that are eminently testable.  (Oh, that nasty code smell...)

7. So, finally, you can start writing some real test at this point.

8. Write unit tests for date-related parts: from distant past to distant future. We have today, yesterday, and many other possibilities.

9. Perform the aforementioned practice in small iterations.

10. And, actually, how to start? The first thing that you do is have a look around. Michael says that he normally spends the first morning on a new case looking around. Are there any tests yet? Sometimes there are. Often there is a test target, and it has the boilerplate test in there, and that’s it. He says that he starts with the model -as a general rule. (Because it gives you a sense of what the app's core is about.)

11. Do not change the original code.