做网站有自己的服务器广东深圳有几个区

做网站有自己的服务器,广东深圳有几个区,郑州网站开发公,百度蜘蛛抓取网站你是怎么编写单元测试的呢#xff1f;很多人的做法是先把所有的功能代码都写完#xff0c;然后#xff0c;再针对写好的代码一点一点地补写测试。 在这种编写测试的做法中#xff0c;单元测试扮演着非常不受人待见的角色。你的整个功能代码都写完了#xff0c;再去写测试…你是怎么编写单元测试的呢很多人的做法是先把所有的功能代码都写完然后再针对写好的代码一点一点地补写测试。在这种编写测试的做法中单元测试扮演着非常不受人待见的角色。你的整个功能代码都写完了再去写测试就成了一件为了应付差事不得不做的事情。更关键的一点是你编写的这些代码可能是你几天的工作量你已经很难记得在编写这堆代码时所有的细节了这个时候补写的测试对提升代码质量的帮助已经不是很大了。所以想要写好单元测试最后补测试的做法总是很糟糕的仅仅比不写测试好一点。你要想写好单元测试的话 最好能够将代码和测试一起写。你或许会说我在功能写完后立即就补测试了这不就是代码和测试一起写的吗其中的差异在于把所有的功能写完的这个粒度实在是太大了。为一个大任务编写测试是一件难度非常大的事这也是很多人觉得测试难写的重要因素。要想做好单元测试关键就是工作的粒度要小。I’m not a great programmer; I’m just a good programmer with great habits.我不是一个伟大的程序员只是一个有着好习惯的优秀程序员。—— Kent Beck任务分解是每个程序员都应该拥有的好习惯即便你 想写好单元测试也要从任务分解开始。所以你需要把一个要完成的需求拆分成很多颗粒度很小的任务。粒度要小到可以在很短时间内完成比如半个小时就可以写完。只有能够把任务分解成微操作我们才能够认清有足够的心力思考其中的每个细节。千万不要高估自己对于任务把控的粒度 一定要把任务分解到非常小这是能够写好代码写好测试的前提条件甚至可以说是最关键的因素。当我们把需求拆分成颗粒度很小的任务时我们才开始进入到编码的状态。而从这里开始我们进入到代码和测试一起写的状态。编写单元测试的过程对于一个具体的任务我们首先要弄清楚的是怎么样算是完成了。一个完整的需求我们需要知道其验收标准是什么。具体到一个任务虽然没有业务人员给我们提供验收标准我们自己也要有一个验收标准我们要能够去衡量怎么样才算是这个代码写合格了。经过我们这一系列关于测试的介绍你应该已经知道我要说什么了一个任务的代码要通过测试才算编码阶段的完成。但测试用例从哪来呢这就需要我们设计了。不同于业务测试的测试用例我们现在要写的是单元测试。而我们要测的单元现在还没有写所以没有人会给我们提供测试用例单元测试的用例只能我们自己来。还记得我们在实战里怎么做的添加 Todo 项吗接下来我们就结合这个部分来谈谈具体怎么做。我们首先要确定的是待测单元的行为也就是要实现的类里的一个函数它的行为是什么样的。或许你已经发现了这其实就是一个软件设计的过程。这里的设计指的是微观的设计就是具体的一个函数准备写成什么样子。通常到了动手写代码这一步大的设计已经在前面做完了。因为我们现在不仅仅要写代码还要写测试。所以我们在设计这个函数接口时还必须增加一点考量它要怎么测。在添加一个 Todo 项时我们经过设计出来的函数接口就是下面这样。TodoItem addTodoItem(final TodoParameter todoParameter);有了一个具体的函数接口设计我们就可以针对它进行更具体的测试用例设计也就是设计测试用例来描述这个接口的行为。是的这里我们并没有着急写代码。对很多人来说写代码的优先级很高但是如果不在这里停一下的话你可能就不会去思考是否还有要考虑的问题而是直奔代码细节去了。而当我们专注于细节时有限的注意力就会让你忽略掉很多东西。所以 先设计测试用例后写代码这是一个编码习惯的问题。有了添加 Todo 项接口之后我们就准备了两个测试场景添加正常的参数对象返回一个创建好的 Todo 项有了测试场景接下来把这些场景实例化出来这个步骤相对来说就比较简单了。比如对于添加正常的参数对象来说那什么样的参数对象是正常的我们就代入一个具体的正常参数比如 foo。有了这个实例化过的参数我们就可以把具体的测试用例表现出来了。Testpublic void should_add_todo_item() {TodoItemRepository repository mock(TodoItemRepository.class);when(repository.save(any())).then(returnsFirstArg());TodoItemService service new TodoItemService(repository);TodoItem item service.addTodoItem(new TodoParameter(foo));assertThat(item.getContent()).isEqualTo(foo);}在实际的工作中究竟是先写测试还是先写实现代码这是个人工作习惯的问题。当我们有了测试用例之后其实就是把一个具体的任务进一步拆分成更小的子任务了。只要我们完成一个子任务我们就可以做一次代码的提交因为我们这个时候既有测试代码又有实现代码而且实现代码是通过了测试的。测接口还是测实现不知道你是否注意到了在前面我一直在说我们要测的是函数接口的行为。我一直说单元测试是一种白盒测试。在一些人的理解中白盒测试的关注点应该是内部实现。那单元测试到底应该关注接口还是应该关注实现呢或许你还不清楚二者之间的区别让我们把前面添加 Todo 项的例子拿过来。如果采用更加面向实现的做法我们应该对 addTodoItem 这个函数的内部实现有进一步的约束就像下面这样。Testpublic void should_add_todo_item() {TodoItemRepository repository mock(TodoItemRepository.class);when(repository.save(any())).then(returnsFirstArg());TodoItemService service new TodoItemService(repository);TodoItem item service.addTodoItem(new TodoParameter(foo));assertThat(item.getContent()).isEqualTo(foo);verify(repository).save(any());}这段代码中核心的差别就是增加了一句 verify这也就意味着我规定在 addTodoItem 的实现中必须要调用 repository 的 save 函数。你或许会好奇repository 本来就要调用 save 方法那我在这里校验它调用了 save 方法似乎也没什么大不了的。单独这么看确实看不出什么问题但是如果你有很多测试都是这么写当你准备重构时你就会发现问题了。很多团队代码一调整测试就失败一个重要的原因就是代码实现和测试之间紧紧地绑定在了一起。因为测试约束的是实现细节而只要调整实现细节测试当然就失败了。这也是很多团队抱怨单元测试问题很多的重要原因。所以 在实际的项目中我会更倾向于测试接口尽可能减少对于实现细节的约束。其实这个原则不仅仅是在接口层面上在一些测试的细节上也可以这么约定比如下面这行代码。when(repository.save(any())).then(returnsFirstArg());这其实是一种宽泛的写法所以用了 any。如果严格限制的话应该严格限定一个非常具体的参数。when(repository.save(new TodoItem(foo))).then(returnsFirstArg());使用 Moco框架我们设置模拟服务器可以设置得非常具体像下面这样。​​​​​​​server.request(and(by(foo), by(uri(/foo)))).response(and(with(text(bar)), status(200)));也可以设置得非常宽泛像这样。server.request(by(uri(/foo))).response(bar);除非这个测试里面有多个类似的请求必须要做区分否则我倾向于使用宽泛一些的约束。这在某种程度上会降低未来重构代码时带来的影响。不过实话说要想完全消除对于实现细节的依赖有时候也是很难的。比如在我们前面的 TodoItemService 的例子里面repository 本身也是 TodoItemService 的一种实现细节一旦进行一些重构把 repository 的依赖从 TodoItemService 中拿掉很多测试代码也需要调整。所以在实际的项目中我们只能说尽可能减少对于实现细节的依赖。其实关于实现细节的测试也是一种重复等于你用测试把代码又重新写了一遍。程序员的工作中有一种重要的原则DRYDon’t Repeat Yourself这不仅仅是说代码中不要有重复而且各种信息都不要重复。总结很多团队由于多方面的原因比如设计做得不好导致单元测试写得少。但为了提高代码质量以及更准确地定位问题我们应该多写单元测试。单元测试最好是和实现代码一起写以便减少后续补测试的痛苦。想写好测试关键要做好任务分解否则面对一个巨大的需求没有人知道如何去给它写单元测试。编写单元测试的过程实际上就是一个任务开发的过程。一个任务代码的完成不仅仅是写了实现代码还要通过相应的测试。一般而言任务开发要先设计相应的接口确定其行为然后根据这个接口设计相应的测试用例最后把这些用例实例化成一个个具体的单元测试。单元测试常见的一个问题是代码一重构单元测试就崩溃。这很大程度上是由于测试对实现细节的依赖过于紧密。一般来说单元测试最好是面向接口行为来设计因为这是一个更宽泛的要求。其实在测试中的很多细节也可以考虑设置得宽泛一些比如模拟对象的设置、模拟服务器的设置等等。感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走这些资料对于【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴上万个测试工程师们走过最艰难的路程希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取