海鸥和服务器端Swift — 2

第一部分: Seagull和服务器端Swift

我已经更新了海鸥版本,现在是0.1.5。 没有大的变化,只有错误修复和改进。 无论如何,Seagull已经距离理想的REST框架又近了一步)

在进行开发时,我获得了一些有关服务器端Swift的新课程。 我想分享我的经验。

Swift和Docker

在Docker容器中运行Swift项目并不像我以前想象的那么容易。 Swift还没有官方形象(真可悲)。 因此,某些项目使用自己的图像。 作为迅速尼奥。 Seagull基于swift-nio,因此我也必须使用它(进行少量修改)

在不同的linux版本上测试项目是一个非常好的主意。 幸运的是,使用docker-compose很容易。 对于Seagull,我为Ubuntu 16.04添加了默认的docker-compose文件,为14.04添加了其他文件。

它是基于Ubuntu 16.04的swift-nio docker映像的docker-compose文件。 现在,我可以使用一个命令在纯Ubuntu 16.04上运行单元测试和测试REST服务器:

docker-compose -f docker / docker-compose.yaml进行单元测试

或适用于Ubuntu 14.04的版本:

只需在参数中设置Linux和Swift版本,然后构建并使用其他映像即可。

docker-compose -f docker / docker-compose.yaml -f docker / docker-compose.1404.41.yaml up res

我花了一些时间来了解它在swift-nio中的工作方式以及如何在我的项目中使用它,但是现在我有了简单而强大的工具,可以在Linux环境中测试我的Swift项目。 这非常有帮助。

测试框架

这让我感到惊讶,但是Mac上的“嵌入式” XCTest和开源Swift的XCTest有所不同。

这是XCTest中的“新型”异步测试。 简单,我真的很喜欢。 但是,当您尝试为Linux编译项目时,它不起作用。 感谢Docker,我找到了它。

老款式。 不太优雅和灵活,但可以在所有平台上使用。

可编码

我太懒了,在测试中我使用了Swift如何序列化Encodable对象的假设。 我只是将结果与硬编码的字符串进行比较:

XCTAssertEqual(expectedBody,String(解码:字节,如:UTF8.self))

字节 —从服务器获取的编码对象,以及ExpectedBody —硬编码的字符串。

是的,这是一个糟糕的解决方案,可以在以后的Swift版本中更改实现,但现在可以正常使用。 当我没有尝试在Linux上运行测试时。

Linux Swift使用不同的Encodable实现,因此在Mac上序列化的对象和在Linux上序列化的对象具有不同的二进制表示形式。 有些测试失败了,我不得不重写它们。

这个教训是-没有假设! 语言可以在不同平台上以不同方式工作。 在Swift服务器端开发中,我们不必使用任何平台特定的功能和知识。

未完待续…

Github上的 海鸥