一个测试驱动的开源图床系统

时间 2019-11-06

标签一个测试驱动开源系统繁體版

原文原文链接

Motivation

于2019年初对于 TDD, BDD 产生了极浓厚的兴趣, 可是测试驱动开发的模式形成了开发进度的严重脱缓, 致使没法及时的交付. 以及业务中各方对于测试驱动开发也没有多少兴趣, 因此选择从我的项目中尝试测试驱动开发, 在找了不少方向, 发现不多有成熟的开源图床系统, 遂对这个方向产生了兴趣, 这为其一.html

从做者进入前端领域以来, 一直坚守 React 技术栈, 但其实在使用中对于 React 技术栈并无太深刻的研究, 由于业务须要的是及时交付, 而不是技术的深刻, 因此在将来极可能该系统会深刻的探索 React 的各类开发模式, 探索 React 的 Hook, Suspense, 服务端渲染, e2e 测试.前端

ant.design 是很是优秀的 React UI 库 github.com/ant-design/…, 在当前业务线一直在使用, 一样没有深刻的探索和参与贡献. 在该项目中也会使用该库做为 UI 库.react

成熟的系统会提供 API 给第三方来集成, API 的格式也在发展, 可是在平时的开发都没法严格遵循 RESTFul 风格, 可是会用这个风格来开发接口是很是重要的, 可让你必须去熟悉 HTTP status code, 因此你不须要在面试以前去背这些 code 的语义了👍. 所以该系统会严格遵循 RESTFul 的接口风格, 将来也会浅尝一下 GraphQL 🍻.webpack

CI/CD 持续集成, 持续部署是在敏捷开发中很是重要的一节, 保证你在提交代码的时候能够不破坏已有的功能. 在本地的开发环境不多本身手动去测试多种环境下的表现. 使用 Node.js 10 在本地开发, 可是有可能会部署至 Node.js 8 环境下, 这时候让持续集成帮助你在 Node.js 8 下运行测试. 一样, Mac 做为开发机器, IE 的测试很麻烦, 让持续集成去作吧. 持续部署能够减小手动操做的麻烦, 让机器去作. 采用了 Github 的 Action 来作持续集成和持续部署, 即便不算完善, 但也是足够使用了, 而且提供 Windows 和 Mac 环境, 很棒 !!! 重要的是 free 嘘~~nginx

试用 BFF 层, 该项目只使用了 bff 层托管 index.html, 这足够了, 接口仍是交给后端去作.git

还有一些其余能力, 项目的架构能力, 响应式设计 & Coding.程序员

项目架构

项目分为前端, 后端, 数据库和网关四个部分, 网关用的 nginx, 数据库是 MongoDB. 体如今该仓库之中的有两个部分前端和后端.github

前端

浏览器层

底层 UI 库为 React, 上层 UI 库为 antd. 路由使用 react-router. 代码打包器使用 webpack, css 预处理器 less. 代码预处理器 babel, 测试框架 jest, 浏览器兼容测 karma+chai+mocha, 浏览器 e2e 测试 jest-puppeteer.web

静态资源发布策略?

在 github Action 中将资源打包而后发布至 ALI OSS 中.

BFF 层

web 框架 express, 测试框架 jest

如何更新 index.html 至最新版本的?

index.html 会跟随静态资源的发布发布至 ALI OSS 中, 而后在部署完成以后从 oss 之中下载下来, 下载 index.html 会在 CD 中执行.

后端

web 框架 express, 测试框架 jest, 接口测试工具 supertest.

beta 环境和 production 环境

tuchuang.space 的环境分为 beta 环境, 供给测试用户进行使用, 该环境和 production 几乎一致, 不过是用来测试最新版本的 tuchuang.space. production 环境为最稳定的环境, 提供给全部的用户.

功能

上传文件至 cdn, 获取文件的访问地址. 支持 png, webp. gif, jpg, svg 格式的图片
获取移除文件的 key, 而后经过 DELETE 方法移除该图片, 这里使用 arc 工具做为示例, 移除文件的接口文档可见官网

Roadmap

还没有肯定, 容易变化, 能够去项目的 Backlog milestone 或 issue 查看

结语

测试驱动是很是棒的, 可是做者我的认为测试驱动的学习曲线比较陡峭, 以及前端领域目前还都没有一个完美的浏览器测试方案, 因此在使用测试驱动的时候开发项目是比较纠结的, 何时应该使用测试驱动而何时不适用测试驱动是一个比较难以判断的问题, 做者也一直在学习, 对于测试驱动, 做者我的认为对于程序员来言是必备技能.

因为该项目并非产品驱动, 而是技术驱动, 因此能够有更多的时间来深刻技术的探索, 只有当程序员对技术特别熟悉才能投入使用, 而且深刻探索这个技术究竟是解决了什么问题, 若是有想要对技术深刻探索的能够一块儿👋.

也许该项目的复杂度达不到有些公司业务的复杂度, 可是能够在该项目之上慢慢的探索, 最终也许能反馈给业务线之上, 很强的技术深度可让你在业务线上有更多的话语权.

更多的东西能够去阅读源码得到🧐.