背景

如果想了解TDD的话，网上的文章会比较多。
如果想理解并且应用TDD的话，不只要在代码层级
我理解的TDD，编程都是灵活的，所以经常被人批是墙头草。

试验

本文主要是对之前的一片旧文进行改造怎样上传整洁的python项目
该文章的主要想法是如何上传整洁的python 项目，文章对不对先不要想。先抛出几个问题

问题

你看到这篇的文章的第一个反应是什么？
你会不会质疑一下这篇文章，思考一下命题本来就就不成立，
文中的方法根本就没有用武之地，
给出的github地址，无效？，clone不下来，跑不了项目？

一些生活中没有测试的例子

举一个例子，很多人在写代码作业的时候，都只会push到代码仓库，但却从来没想过要pull下来，用IDE跑一下，看看到底是否可以run.
再举个例子，当你想在网上找个轮子，抄一抄，改一改，最害怕什么，我最害怕的是这个代码没有README，或者README写了还不如不写.
再举一个例子，我相信大部分人，在学某一项新技术，并且技术门槛比较高的时候回发现一个问题，那就是找了入门的文章，但是，却看不懂，因此优秀的入门文章虽然看着都很简单，但其实耗费了作者很大的心理。

TDD 可以在别的领域中应用

我之所以写那篇怎样上传整洁的python项目，原因是因为我上传的python项目不整洁，我想要找到一个方法去解决问题，因此做了一些spike，一步一步慢慢的找到了解决方案。如果我和其他的文章一样，讲一遍，遇到了啥问题，咋解决的话，那我相信大部分看到该文章的程序员其实都不知道我在中间过程中遇到了什么问题。
因此，我最开始做了一个决定，就是写一点文章，照着文章内容，更新一下代码。最后要做到的验收就是 pull代码库，一键启动。这看起来和TDD没有关系，但是全篇文章的行文脉络是以验收标准为目标进行书写的。所以我可以站在一个测试者，一个初学者去分解一下问题，最后完成一篇文章。
大多数时候我们的文章是无法执行TDD思想的，本篇文章也是一样，因为一个很重要的原因是没有可以实际操作很应用的验收标准或者测试。或者一些文章有一个标准化实例，就是作者自己。如《冥想三个月，给我带来了什么》。作者自己便是实例，没有标准的流程也没有标准的结果。所以自然无法TDD。
然而，大多数的流程相关的教程，其实是可以用TDD思想去写的比如《如何用python 打印hello world》如果跟着作者的流程最后什么结果都没有，那自然是作者的失职。但大部分程序员的文章都还只是分享，没人愿意多那一些功夫，想想，是不是可以通过测试，来驱动出来整个文章。因此优秀的入门文章才那么少。

TDD 在写作方面的应用

不知道有没有人发现，写作大纲其实有用到TDD的思想，先确定一个故事背景，然后往里面填充内容，到达自己想要的气氛。没有大纲的文章，不一定不好，但有时会令人摸不着头脑。古龙的《游侠录》虽然叫做游侠录，然后游侠只存在于开头和结尾，我一直不清楚这个书名是怎么来的。
不需要严谨的TDD，但是最好要有测试标准，如果作为教程少了验收标准的话，那大多数人都会看的云里雾里，能看懂的人其实不看也自会知道答案。
TDD 更容易使行文清晰，很多文章中的跳步明显，省去了一些关键步骤，导致了读者丈二和尚摸不着头脑，如果作者真正对流程进行分解的话，每一个小段想要达到的里程碑其实是很明确的，同时也可以引出文章以外的思考，以及阐述自己在研究过程当中的思考，和取舍。
如果不是艺术作品，留下足够多的思想脉络是很有助于去让读者理解作者当时的所思所想。就好比写了上千行代码，很多小点都会忘记，但是如果给一个测试实例，你可能就会回忆起某一个设计上的闪光点，那时是怎么想的，又是怎样取舍的。