在开始写测试前要先搞清楚一个问题：什么时候写测试？有一种“测试驱动”的开发原则，这种原则要求先写测试，再写实际代码。这种方法听起来有些反直觉，但实际上有些道理，比如我们做一个工具，我们可能会先对这个工具的作用有个明确的预期，然后再开始做工具。再具体点的例子就是说，假如我要造一艘船，我会首先找一条适合我这个船的河，再到河边弄个小船坞，准备船一造好就先在河里测试一下，如果有不行的地方再来改造下。这里的船坞和小河就是测试环境，开着刚造好的小船去河上跑几趟就是测试代码。至于人工测试就相当于我每次对船有所调整，就自己开着船去河上跑一趟，测测最大速度，转弯灵活不，最大承重多少。而自动化测试，就相当于我做了一个机器人，每次船一调整就由这个机器人去测一下船的各项性能。基于上面的分析 ，先把测试代码写好，再把实际代码写好，也是一种很好的方法，这样可以保证写出来的代码，马上就进行测试，生产出的代码更加健壮。尤其对于“工厂”来说，严格的测试很有必要。对于新手来说，先写代码再写测试也很正常，写测试总比不写要好。但是可以尝试在写下一个新功能或修复新的bug的时候，先写下测试。现在开始写一个测试：前面的polls 应用现在就有一个小 bug 需要被修复：我们的要求是如果 Question 是在一天之内发布的， Question.was_published_recently() 方法将会返回 True ，然而现在这个方法在 Question 的 pub_date 字段比当前时间还晚时也会返回 True（这是个 Bug）。先用django的shell工作来复现一下这个bug:workon DjangoStudy
:: 进入虚拟环境
cd /d e:\code\mysite\
:: 进入工作目录
py manage.py shell
:: 进入shell
>>> import datetime
>>> from django.utils import timezone
>>> from polls.models import Question
>>> # create a Question instance with pub_date 30 days in the future
>>> future_question = Question(pub_date=timezone.now() + datetime.timedelta(days=30))
>>> # was it published recently?
>>> future_question.was_published_recently()
True
因为将来发生的，肯定不是最近发生的，所以代码有错误 。未完待续……

我所使用的Pycharm是2022.2 Professional Edition版本以往，我们用命令创建Django是这样的：django-admin startproject djangoProjectDemo
然鹅，用上神器Pycharm，能点击鼠标操作，我绝不敲击键盘：如上图所示，新建项目选Django，给项目重命名一下，其他都不管，点右下角“创建按钮”，等待几分钟，项目创建成功。编辑配置快捷按钮入口编辑配置菜单入口一般就是配置IP、端口、日志等：初学，为了能马上运行项目，发IP给对面的程序媛炫耀，而不至于她访问不了，第28行改成这样子：ALLOWED_HOSTS = ['*']
为了显示中文，107-109行改两个参数：LANGUAGE_CODE = 'zh-hans'
TIME_ZONE = 'Asia/Shanghai'
USE_I18N = True
USE_TZ = True
一切准备就绪！！！开始运行！！！**运行项目的一般命令是： **python manage.py runserver 192.168.1.111:80
Pycharm创建的项目为了不污染操作系统环境，下载的Django默认放到了我们项目文件夹里，因此需要加Python 的绝对路径。然鹅，用上神器Pycharm，能点击鼠标操作，我绝不敲击键盘：直接运行也是可以的，注意我们运行的是项目，而不是之前学基础语法的时候，习惯性地点右键运行setting.py文件哦上面那长串代码，其实是点运行得来的命令，既然用Pycharm，还记那么多命令干嘛：看到下面一串正常启动服务器的提示，大功告成：最后， 码字不易，麻烦关注一下我的CSDN号嘛

如果你现在赶项目，就直接跳到符合的标题查看解决办法。如果你对理论思考不太感冒，也可以直接跳到指定标题。如果你是学习者，极客，时间充足，希望你能够耐心的看下去，因为你在这里，不仅仅可以找到解决办法，更重要的是找到解决问题的思路和学习思考的方法。大浪淘沙，编程道路上，绝大部分新人程序员，都被淘在了环境搭建及写代码前的各种配置上。我曾经也一样，无数次想咂电脑，呐喊：我特么学个技术，为什么还没起步，就给我搞出这么多屁事！这不怪你们，因为你们才是程序世界的主力军，挡你们者万死莫赎，都怪他们。我仅仅希望，程序世界留住你的原因，有我一个。如果你以后成了大神，希望你也能为改变这个生态而做出一份自己的贡献，给这些生力军，主力军，保驾护航。我们为何总会碰到一些觉得是脱裤子放屁多此一举的功能不只是你，我也一样，任何人都一样。也不只在编程领域里，在生活中各个方面总能碰到一些让人不理解的地方。我们不从哲学式“存在即合理”的角度去讨论问题，但我们要承认，我们对某一件事物的不解都来自于不了解。可能我们每个人都知道，只是，我们经常没法很轻松的得到想要的答案而无奈而已。我在这里要和你们分享几个角度，去看待或者对待一些看起来莫名其妙，多此一举的事物，尤其在编程领域，这应该会让你觉得没有那么难受，即使没有真正搞懂其中缘由。1.它可能是一个为了超大型项目服务的技术点。屏幕前的你，也许是一个学生，也许是一个刚踏入编程工作的程序员，还远远想象不到我们正在当做工具/玩具一样的编程语言或技术点，如果用到很多很多很多的人需要去一起配合完成的项目中，会是个什么样子，而这只有经历了才能感同身受。但请你记住，工作中，永远不会是你一个人在战斗。你要对每个技术点，时刻抱着工程思想和态度。2.它可能是历史原因，但因已经流行，体量大到修改成本让人望而却步。任何一个项目，都不是一蹴而就的，慢慢发展进步，却又要做到兼容旧功能。而往往，很多项目初期，因为各种原因，没法做到面面俱到。我个人甚至在工作初期，使用一个微信开发者平台中很冷门的接口时，找到了BUG，并提交，那时晚上10点，腾讯那边加班改了，虽然影响并没有那么严重，但对当时的我来说，是比较有感触的。腾讯？怎么会在对外开放的接口里有BUG？那么大公司，怎么可能呢？甚至这种想法， 影响我当时追BUG的态度，尽量不去怀疑腾讯那边出了问题，而怀疑自己。但我们也要承认，大公司出问题的概率极低，我们调错，永远要在概率最大，时间成本最低的可能点开始。我想说，有时，你要相信自己，你的认知并没有错！可能，只是历史原因。如何安装多个版本的python并且起不同的名字去执行首先说，什么情况下可能需要安装多个版本。1.你可能在已经安装过旧版本的python环境中，想尝试新版本，又不能删掉旧版本 2.你可能因为学习不同的框架，不同的框架不同的版本，所要求的最低python版本不同。这个问题不能独自解决，是因为没有搞清楚到底什么是环境变量，环境变量的工作原理(关于环境变量的概念和配置方法，不在这里解释，可以自行去搜索)。我没有看任何文档，仅仅对于环境变量的理解，就做到了，不管是哪个操作系统道理是一样的。下面一步一步来看看，我的逻辑思路。我们经常会在命令行执行命令，如：# 跑python
python hello.py
那命令行就会根据你第一个空格前面的python这个单词，再根据系统变量设置的path中列出的那些路径，在每个路径下依次寻找python.exe可执行文件，如果有就会去执行。至于后面的hello.py是这个可执行文件规定的带参数方式而已。比如 go 的执行：# 跑go
go run hello.go
看截图。先看当前环境变量(注意，有两种：用户变量和系统变量，两个地方都要查看)：从结果上，python是在截图中的蓝色那个目录下找到的。再看对应目录下的截图：它就是找到了图中这个可执行文件，去执行的。那我们完全就可以改变这个exe文件的名字，比如：python333.exe。改完后再去命令行执行 python hello.py 是没用的，因为找不到了。你只能用 python333 hello.py 。你甚至可以改成go333.exe，然后执行go333 hello.py，当然不建议这么做。那到了这里你就可以猜到，我们完全可以安装不同版本的python，把他们的程序目录都添加到环境变量中，然后各自的python.exe，改为他们对应的版本，做出区别，根据情况，用不同的版本去执行就可以了。虚拟环境是什么，为什么产生，怎么用首先，引出几个概念，全局环境，全局依赖包。如果你的电脑，只有你一个人在用，并且还没有涉及过虚拟环境，那你到目前为止，所有python开发环境的操作都处于全局环境中，安装的依赖包也都在全局环境中。如多个python版本的情况一样，如果你不同的python项目，需要不同的python版本，那也必然需要不同的依赖包。如果你经历比较多的项目，其实很多一次性的依赖，你并不希望安装在全局环境中，想让他随着项目一起存在和消失。所以出现了虚拟环境，我们需要虚拟环境，去把每个项目以及他的依赖隔离开来。隔离：是一种思想，是复杂系统中常用的解决思路，他有不同的实现方式。你会在后面长期的编程经历中慢慢体会。如，编程语言中的命名空间，Linux系统中的命名空间，虚拟机软件，Docker等等。我们在开发时对依赖的需求，有两个阶段，一个是项目还没有创建，为了开发而准备的时候，另一个是项目创建后开发途中。首先，如pip，venv或virtualenv这些，就是项目创建之前，就需要用到。你没有pip，你没法管理依赖包，更别提创建项目了，先要用pip安装了django，你才能创建django项目。所以这类依赖包，是不同项目共用的，需要安装在全局环境中，不能混淆。其次，在开发django项目途中，你可能需要其他依赖包，就要在该项目的虚拟环境下安装。概况：virtualenv是python3.3之前用的，venv是之后用的。python3.6之后安装时默认带了venv，直接用就可以了。# 进入指定目录，创建虚拟环境。如：D:\code\python\testenv
python -m venv env_name
执行完如上命令，会在你的D:\code\python\testenv目录，生成一个文件夹，名字叫：env_name。# 1.启动虚拟环境前，你处于全局环境中。
# 2.启动虚拟环境。
# 执行虚拟环境目录D:\code\python\testenv\env_name下的Scripts目录下的activate.bat脚本
cd code\python\testenv\env_name\Scripts
activate.bat
# 成功执行完毕后，你处于env_name这个虚拟环境中。
# 3.关闭虚拟环境。
# 执行虚拟环境目录D:\code\python\testenv\env_name下的Scripts目录下的deactivate.bat脚本
cd code\python\testenv\env_name\Scripts
deactivate.bat
# 成功执行完毕后，你再次处于全局环境中。
# 记住：你要根据你要安装的依赖包，属于哪里，正确切换到对应的环境中去安装。
pycharm直接打开已创建django项目时依赖包引入错误如图：原因：pycharm不知道你打开的这个项目，相关的依赖包在哪里。你自己可能知道，是在例如：djangotest_env 的虚拟环境下。解决办法：配置pycharm的解释器，解释器可以理解为python.exe，因为python是解释型语言，通过python.exe解释执行python代码，所以叫解释器也没毛病。它在虚拟环境目录下的Scripts目录下，至于全局环境的解释器当然就在python安装目录的Scripts目录下。看过很多人说pycharm社区版不行，企业版才可以，或怎么样，都没有的事，是他们不会用。配置解释流程，看图：如下图，因为pycharm默认是使用全局环境的解释器，而我，因为是在叫做py396_env的虚拟环境目录下安装的django，所以django相关的依赖包，pycharm不知道，需要配置，告诉它。继续看图，选择新建或配置虚拟环境解释器：配置界面解释：选择对应解释器，apply，OK，配置完毕：配置完成后，就不会报错了：打开pycharm命令行报错：无法加载文件 D:\code\py396\py396_env\Scripts\Activate.ps1，因为在此系统上禁止运行脚本。或执行activate脚本报错或没有任何反应。报错如图：如果按照新人角度，看到这块儿错误提示中，有activate脚本执行的语句，就会下意识认为是虚拟环境启动失败了。其他语句也不会去管，也看不懂。而根据习惯，我们会试图进入到对应的虚拟环境启动脚本目录下，如D:\code\py396\py396_env\Scripts，执行activate.bat。然而，报错如下：那继续根据提示，前面加上当前目录去执行：.\activate.bat然而，反应如图，没有任何反应：开始讨论：首先，我们需要通过如上几个反应中，学会思考和发现问题。从上述截图列表中的反应，我们需要搜集到如下几个信息：1.打开命令行时，pycharm试图自动找到对应虚拟环境启动脚本所在的目录，并执行看似启动脚本的东西，D:\code\py396\py396_env\Scripts\Activate.ps1，只是扩展名为，ps1。2.根据报错所知，我们因为某些原因，被禁止执行该启动脚本了。3.我们指定之前所知的启动脚本activate.bat，没有任何反应。而我们在虚拟环境创建时，已经在cmd命令行中成功执行成功过虚拟环境启动脚本。所以，说明，cmd命令行，和pycharm这个终端，不太一样。这时，我就去搜索，ps1扩展名是干什么的，他是powershell脚本。由此，我得出结论。1.pycharm终端是通过powershell实现的，并且脚本要执行.ps1而不是.bat2.虽然不知道具体原理，但至少可以确定，pycharm会根据打开的项目中某些文件上的信息，去准确定位到了对应虚拟环境及其启动脚本，因为我们根本没有设置过。3.powershell权限受限了，无法执行启动脚本了。然后，我就去搜索这个错误相应的解决方案，一搜一堆。发现了一个概念：set-executionpolicy xxx，从这个名词就可以看出，是设置执行策略的。这种系统安全相关的设置，一般需要最高权限，所以win窗口搜索powershell，右击用管理员身份打开：脚本执行策略可以从微软官网查看到：Set-ExecutionPolicy（Microsoft.PowerShell.Security）Restricted：不加载配置文件或运行脚本。 Windows 客户端计算机的默认执行策略。(默认)RemoteSigned：要求从 Internet 下载的所有脚本和配置文件都由受信任的发布者签名。 Windows 服务器计算机的默认执行策略。设置并查看当前脚本执行策略：至此，再次到pycharm的命令行中，执行./activate，就能成功切换虚拟环境了。如图：如果懒得跳转目录，并执行命令，你也可以直接关闭命令行，重新打开，那pycharm会自动给你执行启动脚本切换到虚拟环境中。注意是关闭命令行，而不是最小化，如图：太晚了，今天先这样，之后再补更新… … …