Tips for a novice for the old code to write test programs-test code, programmers-it news A new writing test for old code program experience

I insist on going to the gym to exercise, weightlifting, I like this feeling of making it stronger and healthier. About two months ago, my knee started feeling pains, but I was still strong in practice.

I wanted to make myself stronger, completely ignore your leg health problems, forcing himself to continue weightlifting. As you can imagine, pain does not improve on his knees, exhausted after a workout every time I take a longer time to recover.

As a Rackspace company junior programmers (Airbrake development group), I had a similar feeling, it urged me to keep a large number of output code and thought it would make the product stronger. The knees when squatting at a time when, as I have to put up with the pain, untested features of the old start to buckle under the weight of a large number of new features, began to break.

My physical therapist eventually convinced I should focus on doing rehabilitation exercises, recovery must not go before lifting weights. He said that when after a knee problem, muscles become stronger after the strong, my progress will be faster, less likely to injure themselves, making themselves miserable.

Bearing in mind that these pieces of advice, I saw a link between it and the work. I force myself to write test code to the old code, the old features, and this makes my development progress faster, more confident of the code, no longer worried about developing new code will break old code functionality.

Here is what I learned during this process several critical points:

Development tools are important

I'm using RSpec, Capybara, FactoryGirl and Selenium to test my Rails application. In writing the tests before the code, you have to look at these tools. Otherwise, debug these waste a lot of time to test your code.

Some easy tasks, for example in testing the clear database before and after the test, they make sure you get it right, fast, repeatable testing plays an important role. For these tasks, you can use the database_cleaner gem.

If you're a team player first person to write the test code, test tool choice is particularly important at this time, it will affect the other members of the team to test accepting. The entire team must be submitted to the test procedures, so you need to make this process as easy as possible,--in a robust and flexible tool.

Just tell you now what the existing code, but not tell you the code actually is as it should be.

As we start testing other people's code, I found there is a habit, starts with the assumption that the code is correct, to meet the requirements, so the code to pass the test case. Sometimes that is not a problem, but sometimes the code is through test code changes just because they write.

You can't help but try to do things the easy way, would assume all of the code is up to date, to meet the requirements and write tests to verify these assumptions. That led to a reverse mode of test-driven development: code became the basis and standard of the test.

Safe is a willingness to explore the code first, experienced programmers prefer to write clear code, you can see it trying to achieve the functions of the code.

Full testing is not possible, do not ask yourself

Write test programs for the entire project, you may need to treat it as a full-time job. Of course, we all wish 100% (+) test coverage, just like we all want no dirty dishes in the sink. However, another way is if you need plates, cleaning the dishes you want. We use this tactic for a new code to write test programs, old code writing when we encountered during the development of test procedures.

I suggest new programmers should be able to write tests for old programs, so that it can force you to learn the old code base, giving you access to a deeper muscle memory. But be sure to follow these principles.

一个新手为老代码写测试程序的心得 - 测试代码,程序员 - IT资讯
一个新手为老代码写测试程序的心得

我坚持去健身房锻炼身体，练习举重，我喜欢这种让自己变得更强壮、更健康的感觉。大约两个月前，我的膝盖开始感觉抽痛，但我仍然坚强去锻炼。

我一心想让自己更强壮，完全忽视了腿上的健康问题，仍然强迫自己继续举重。你可以想象出，膝盖上的痛没有好转，每一次精疲力尽的锻炼后我都需要更长时间的恢复。

作为一个在Rackspace公司的初级程序员(在Airbrake开发组)，我经常会有一种相似的感觉，它催促我不停的大量产出代码，以为这样能让产品更强壮。当正如我的膝盖每次在下蹲时都要忍受痛苦一样，未经测试的老的功能特征在大量出现的新功能的重压下开始变形，开始断裂。

最终我的理疗师说服我应该重点做康复锻炼，恢复前不要再去举重。他说，当膝盖上的问题好了之后，肌肉变得更结实有力后，我的进步会更快，也更不容易弄伤自己，让自己痛苦。

铭记了这些忠告，我看到了它和工作之间的联系。我强迫自己去给老代码、老功能写测试代码，这样使得我的开发进度更快，对代码更有信心，不再担心开发新代码时会破坏老代码的功能。

下面是我在这个转变过程中学到的关键几点：

开发工具很重要

我使用RSpec, Capybara, FactoryGirl和Selenium来测试我的Rails应用。在写测试代码之前，你要先研究一下这些工具。否则，调试这些测试代码浪费你大量的时间。

一些简单的任务，例如在测试前和测试后清除数据库，它们对保证你能正确的、快速的、可重复的测试起着重要作用。对于这些任务，你可以使用这个database_cleaner gem。

如果你是团队中第一个来写测试代码的人，这个时候测试工具的选择尤其重要，它会影响团队其他成员对测试的接受。整个团队都要提交测试程序，所以你要让这个过程尽可能的简单，——采用强大、灵活的工具。

现有的代码只是告诉你现在做成了什么样，但不是告诉你代码实际应该是这样。

当开始测试别人的代码时，我发现有个习惯，首先假设这些代码是正确的，符合要求的，所以这些代码中能够通过测试用例。有时这样是没问题的，但有时这些代码之所以通过测试只是因为测试代码是按照它们写的。

你忍不住会图省事，会假设所有的这些代码是最新的，符合要求的，然后写的测试来证实这些假设。这就导致了一种反向的测试驱动开发模式：代码成了测试的依据和标准。

安全的做法是探求代码最初的意愿，资深的程序员更喜欢写出很明晰的代码，你能通过代码看出它试图实现的功能。

完全测试是不可能的，不要这样要求自己

为整个项目写测试程序，你可能需要将它当作一种全职工作来对待。当然，我们都希望100%(+)的测试覆盖率，就像我们都希望洗涤盆里没有脏盘子。然而，另外一种方法是当你需要盘子时清洗所需的盘子。我们用这种策略为新代码写测试程序，老代码中我们开发的过程中遇到时再写测试程序。

我建议新程序员应该去为老程序写测试，这样它能强迫你学习老代码库，让你获得更深的肌肉记忆力。但一定要遵循上面的这些原则。