When a project is small, or you are just doing something quick, it??™s easy to write quick
ad hoc code to ensure things are working; you can always refer to the full code base to determine
what the application is really doing.
The problem is that once you start working on larger projects, you??™ll quickly find that
reading through the full source code trailing a logic path to locate a bug can be quite time consuming.
Having to do it six months or more after having last worked on the application will
make it even harder! So with that in mind, here??™s a list of our top five reasons to bother with
unit testing:
1. Assures you that your code works as you expect it to: This is a pretty obvious reason,
since it??™s the whole point of any test. If you??™ve been a programmer for any length of
time, you??™ve noticed that sometimes features don??™t always work as advertised (yes, even
in Ruby). Sometimes, your logic is just off. The only way to know if the code you wrote
works the way you intended is to actually execute it. If you let the first time that happens
be in front of your user, you??™ll deserve the lack of faith they put in you and your
work when it doesn??™t work as expected.
Pages:
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296