容器化环境中的黑盒测试与开放盒测试应用程序[关闭]

我们使用容器来部署我们的Node.js应用程序。但是目前，开发人员和大量测试工作是由开发人员在其自己的主机系统上完成的，因此使用了不同版本的工具（尤其是Node.js本身，NPM和Mocha），具体取决于他们使用的Linux发行版中的可用版本。 。

为了标准化我们的开发堆栈，我们希望在容器中执行所有测试，以便每个人都可以使用完全相同版本的工具。应用程序源目录将绑定安装到“测试容器”。

我们现在在这里讨论开发人员应该如何与“测试容器”进行交互。基本上，使用Dockerfile表示法，我们在两个选项之间犹豫不决：



黑盒解决方案：

CMD npm install && npm test

host$ # Running a test suite:
host$ sudo docker run app-test-container

除了启动容器，运行测试不需要任何手动操作。测试保证是可重复的。但是开发人员抱怨在每次测试之前运行npm install可能产生的开销，以及（由于绑定安装）最终导致他们同时启动npm install的多个实例而导致的潜在问题。


解决方案：

CMD /bin/bash

host$ # Starting the test container:
host$ sudo docker run -it app-test-container

app-test-container$ # run tests after dependency change
app-test-container$ npm install && npm test

app-test-container$ # run tests when no dependency change
app-test-container$ npm test

通过该解决方案，开发人员只需获得对容器集的shell访问权限即可与标准的开发堆栈。在需要时由npm install决定，并通过在容器中发出npm test命令手动启动测试。这非常接近他们目前在开发主机上所做的工作。他们还看到了与容器进行交互访问的一些优势，因此可以从那里直接启动node以使用REPL进行临时测试和实验，还可以直接从容器中运行其他npm命令，从而使他们基本上可以腾出安装任何工具直接在其主机上。



所以，我有几个问题：


这些解决方案对您来说理智吗？
您能看到我们在两种解决方案中都没有想到的优点或缺点吗？
总体而言，这是迈向实施最佳实践的好一步，还是您在这里发现了一些反模式？