这是您一直面临的问题。

您无法在上确切地了解，在该点的复杂网络中，在微服务到微服务通信的复杂网络中，单个HTTP交易出错！通过跟踪，您的组织正在生成和存储大量的跟踪数据，而不会以一致的测试形式从中获得价值。

在这里如何解决它。

我们进入了一个新时代的可观察性驱动的开发（奇数），该时代强调在后端代码中使用仪器作为测试中的断言。现在，我们有一种基于痕量的测试的文化开发。借助Tracetest之类的工具，后端开发人员不仅仅是从基于Opentelemetry的痕迹中生成E2E测试，还可以改变我们在最复杂的应用程序中的实施方式，并鼓励速度。

这正是我们在本教程中的演示。完成后，您将学习如何仪器代码并自己运行基于跟踪的测试！

您可以找到完整的source code on GitHub。

过去：测试驱动的开发

测试驱动开发（TDD）是一个软件开发过程，开发人员在代码之前创建测试用例以强制执行应用程序的要求。

相比之下，传统的测试方法是指根据您的软件要求编写代码，然后编写集成或E2E测试以验证您编写的代码是否在所有情况下工作。

使用TDD，软件开发周期发生了巨大变化，因此一旦您的团队就这些要求达成协议，您就可以：

1. 添加一项通过时，并且只有满足这些要求就可以通过。
2. 进行测试并看到失败，如预期的。
3. 写通过测试的最简单的代码。
4. 再次运行测试并查看pass结果。
5. 根据需要重新制定代码以提高效率，删除重复代码，将代码分成较小的零件等等。

tdd已经发现了大量粉丝，因为它可以大大降低错误的速度，而且总体而言，可以提高组织法规的技术质量。但是，鉴于现代基础设施的复杂性，包括云原生技术和微服务的扩散，TDD最终未能在中途见到后端开发人员。

在后端创建和运行基于TDD的测试的痛苦

您知道，进行后端测试需要访问和可见性，与前端单位测试不同，它们在小的，孤立的环境中不运行。您不仅必须设计触发器，还必须访问数据库，这需要某种身份验证方法。或者，如果您的基础架构具有消息总线，则需要配置测试监视的方式并收集相关日志。

如果您的基础架构严重利用了无服务器功能或API网关等资源，则您会面临更大的挑战，因为这些挑战是短暂的，默认情况下是隔离的。您如何从不再存在的lambda收集日志？

对于所有好处，TDD都会创建方案，您可以看到您的CI/CD管道由于E2E测试而失败，而不是 whene 或为什么为什么失败首先发生。如果您可以确定它是否发生在微服务A和B或Y和Z之间，那么您的测试案例有用的工具来指导您如何开发代码，它们是神秘的阻止者，您会重新盲目地试图发展。

如何在TDD环境中添加后端测试

我们将使用node.js项目作为一个简单的示例，以显示分布式环境中集成和E2E测试的复杂性。

要简单地站立测试工具，您需要在您的代码库中添加多个新库，例如Mocha，Chai和Chai HTTP。然后，您需要生成模拟的数据，该数据存储在存储库中，以便使用测试。这意味着在GIT存储库中创建更多与测试相关的新文件夹和文件，使可能已经是复杂的景观了。

然后，要添加单> 测试，您需要添加一个不错的代码：

const chai = require('chai');
const chaiHttp = require('chai-http');
chai.use(chaiHttp);
const app = require('../server');
const should = chai.should();
const expect = chai.expect;

const starwarsFilmListMock = require('../mocks/starwars/film_list.json');

describe('GET /people/:id', () => {
  it('should return people information for Luke Skywalker when called', done => {
    const peopleId = '1';
    chai
    request(app)
    .get('/people/' + peopleId)
    .end((err, res) => {
        res.should.have.status(200);
        expect(res.body).to.deep.equal(starwarsLukeSkywalkerPeopleMock);
        done();
    });
  });
});

从现在开始，您使用完全相同的脆弱语法进行了数十个或数百个测试，以获取覆盖范围TDD的需求。

未来：以traceTest的可观察性驱动开发

奇数是开发软件和相关的可观察性仪器并行的实践。当您部署后端服务时，您可以立即观察系统的行为，以了解有关其弱点的更多信息，从而指导您下一步将开发的位置。您仍在开发一系列商定的软件要求，但您没有花费时间来涵盖所有可能的错误，而是确保您在生产环境中对这些错误有了完全的可见性。

这就是您如何发现和修复危险的软件开发未知的未知数。

ODD的核心是 distributed tracing ，它记录了HTTP请求通过在云本机基础结构上运行的应用程序和API所采取的路径。跟踪中的每个操作都表示为一个跨度，您可以添加主张可测试值以确定跨度是否成功或失败。与传统的API工具不同，基于跟踪的测试对系统响应和 trace结果主张。

利用分布式轨迹奇数的好处是巨大的，可以帮助您和您的团队：

• 了解HTTP请求的整个生命周期，因为它通过您的分布式基础架构传播，无论它是成功的还是完全失败的地方。
• 追踪新问题或创建新的测试，没有系统的先验知识，也没有运送任何新代码。
• 解决代码级别的性能问题。
• 直接在生产中直接运行基于跟踪测试。
• 在您的系统中发现并故障排除可能已经滑过复杂的TDD过程的未知数。

如何将OpentElemetry仪器添加到后端代码中？

像TraceTest这样的平台与Jaeger，Grafana Tempo，OpenSearch和SignalFX等少数跟踪数据存储集成在一起。添加分布式轨迹的最短路径是将特定于语言的OpenTelemetry SDK添加到您的代码库中。流行语言也有auto-instrumentation，例如Node.js示例，我们将在下面创建。

ðâ¡ /p>

例如，在这里，我们如何在几行代码中添加跟踪Node.js/Express-based project：

const opentelemetry = require('@opentelemetry/sdk-node')
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node')
const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-http')

const sdk = new opentelemetry.NodeSDK({
  traceExporter: new OTLPTraceExporter({ url: 'http://otel-collector:4318/v1/traces' }),
  instrumentations: [getNodeAutoInstrumentations()],
})
sdk.start()

git clone https://github.com/kubeshop/tracetest.git
cd tracetest/examples/quick-start-nodejs/
docker-compose -f docker-compose.yaml -f tracetest/docker-compose.yaml up --build

brew install kubeshop/tracetest/tracetest

span[tracetest.span.type="http" name="GET /" http.target="/" http.method="GET"]

tracetest configure

[Output]
Enter your Tracetest server URL [http://localhost:11633]: http://localhost:11633

$ tracetest test run -d test-api.yaml -w

✔ Example Test One (http://localhost:11633/test/ycmoH254g/run/7/test)

const express = require("express")
const app = express()
app.get("/", (req, res) => {
  setTimeout(() => {
    res.send("Hello World")
  }, 1000);
})
app.listen(8080, () => {
  console.log(`Listening for requests on http://localhost:8080`)
})