ZOMBIES：Linux 中国软件开发与测试简便指南（一）

软件开发领域，许多人渴望能连续编写代码而无需中途检查，享受那种一路畅通无阻的快感。这不仅代表了一种高效的工作方式，还体现了开发者技能的认可。然而，这种看似“酷炫”的操作背后，实则潜藏着许多风险。

过度自信的危害

不少开发者，包括我，曾被所谓的“真正开发者”观念误导。在这种观念里，暂停检查代码仿佛是认输的表现，人们觉得只有新手才会这样做。在小团队或个人开发小项目时，许多人往往只顾追求速度，埋头苦干。他们不愿在编写过程中停下来检验代码，觉得这样会打断自己的节奏。这种心态在开发过程中慢慢累积，就像一颗埋藏的定时炸弹。然而，事实是，这种过度的自信往往会导致后续代码要么无法编译，要么运行结果与预期大相径庭。就比如我之前编写的代码，我自以为没问题，但最终各种错误接连出现，严重影响了项目的进度和质量。

这种自信过分，源于一种不切实际的设想。软件开发过程颇为繁杂，我们不能盲目相信每段代码都完美无缺，逻辑和语法错误可能悄无声息地混入其中。

硬编码的便利性与弊端

[Fact]
public void NewlyCreatedBasketHas0Items() {    
    var expectedNoOfItems = 0;
    var actualNoOfItems = 1;
    Assert.Equal(expectedNoOfItems, actualNoOfItems);
}

硬编码值有其特别的魅力。比如在项目启动阶段，为了迅速获得一个可运行的版本，人们常会选择使用硬编码值。在编写购物车相关代码时，若仅是为了初步验证思路的可行性，使用硬编码值可以让我们在较短的时间内搭建出一个能即时给出反馈的初步模型。例如，若预期商品数量为0，但实际在硬编码中设置为1，我们便能迅速观察到程序的基本运行效果，便于我们快速进行调整。

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
[xUnit.net 00:00:00.57] tests.UnitTest1.NewlyCreatedBasketHas0Items [FAIL]
  X tests.UnitTest1.NewlyCreatedBasketHas0Items [4ms]
  Error Message:
   Assert.Equal() Failure
Expected: 0
Actual: 1
[...]

然而，另一方面，硬编码的数值却引发了不少麻烦。在随后的测试过程中，我们会发现不少与实际业务逻辑不相符的情况。如果只是让这些硬编码的数值暂时迎合当前的测试，却未考虑到数据的灵活获取与处理，那么随着程序的复杂化，问题便会层出不穷。以购物车为例，当需要根据实际数据，比如API，获取准确的商品数量时，之前的硬编码值就不再适用了。

测试可失败性的意义

[Fact]
public void NewlyCreatedBasketHas0Items() {
    var expectedNoOfItems = 0;
    var actualNoOfItems = 0;
    Assert.Equal(expectedNoOfItems, actualNoOfItems);
}

有时我们认为简单的检验实在没有必要，觉得那种故意设置失败以检验的测试毫无意义。比如在之前的购物篮测试中，当预期结果是零却硬性设置为一时，有人认为这只是个基础错误，进行此类测试纯属浪费时光。

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
Test Run Successful.
Total tests: 1
     Passed: 1
 Total time: 1.0950 Seconds

确保测试的失败可能性至关重要。在软件开发的复杂过程中，代码量增多，逻辑复杂，我们可能无意中破坏了之前的处理方法。而一个能失败的测试就像是一位忠诚的警卫，一旦出现异常，便会立刻发出警告。

真实数据的引入

我们认识到硬编码的问题后，便应停止虚构数据。接着，要将硬编码的数值更改为API提供的数值。以购物车为例，过去我们固定使用硬编码的数值，而现在必须从API中获取真实的商品数量，以确保代码与实际业务相符。

using System;
namespace app {    
    public interface IShoppingAPI {
        int NoOfItems();
    }
}

引入实际数据时，需注意其调用与处理方法。C#项目需关注相关语法与数据结构。此过程非单纯数据更替，还需确保数据精确与时效。

接口与代码逻辑的关联

using System;
namespace app {
    public class ShoppingAPI : IShoppingAPI {
        public int NoOfItems() {
            return 1;
        }
    }
}

在软件开发过程中，接口设计同代码逻辑的紧密联系至关重要。以购物车功能为例，编写相关代码时，我们需设定接口方法来输出商品数量。若接口返回值采用硬编码，一旦与测试环节对接，必然会出现问题。因此，接口定义必须与实际业务逻辑保持一致，以确保测试时能准确反映出程序运行状态。

同时，我们必须确保接口中的代码逻辑得到准确执行。举例来说，在表示购物篮时，需挑选恰当的数据结构。以C#的集合类型为例，若选择不恰当，可能会引发程序运行时的错误。

基于测试调整代码

测试不通过时，我们应依据测试反馈来对代码进行调整。比如在购物车功能测试中，若发现失败，不能仅仅更改预设的数值。我们必须全面检查代码的架构，区分是数据获取出了问题，还是接口连接出了岔子，亦或是代码逻辑本身有误。通过这种方式，我们才能彻底解决问题，使代码更加稳固可靠。

IShoppingAPI shoppingAPI = new ShoppingAPI();

所以我想请教各位，在你们编写代码的时候，是否有过因为贪图一时的方便而最终陷入后期难以修改的困境？希望各位能分享你们的经历，并对这篇文章点赞和转发。

using System;
using Xunit;
using app;
namespace tests {
    public class ShoppingAPITests {
        IShoppingAPI shoppingAPI = [new][3] ShoppingAPI();
 
        [Fact]        
        public void NewlyCreatedBasketHas0Items() {
            var expectedNoOfItems = 0;
            var actualNoOfItems = shoppingAPI.NoOfItems();
            Assert.Equal(expectedNoOfItems, actualNoOfItems);
        }
    }
}