• 是有些片面,但很赤裸裸的直接。

    你看看身边的java程序员,是不是至少八九成都只是个spring框架的使用者?有多少会写单元测试,功能测试,关注架构?

    别说 TDD (Test Driven Development),连 DDT (Development Driven Test) 都做不到。

    java开发人员离开了Spring, 是不是大部分都得直接跪在那里。

  • 这个东西,没有什么可比性。

    java 面向就业岗位和简历编程。

  • 我推荐使用Cucumber,并非单纯从一个技术的优劣性的角度。比它更方便、更高效的工具一大堆 (MiniTest Rspec RobotFramework .....)。单独讨论这一点就如同讨论PHP是不是宇宙最好的语言一样意义不大。

    如果我们没有真正玩敏捷之前,我们也没有多少使用Cucumber,更多使用 RSpec.

  • 你get到点了。但是需求沟通,写写用户故事就够了吗?仅仅是用户故事,效果还不如传统的软件规格书来的好。

    cucumber并非是最好的测试工具/框架,用它的原因是正好,我们在用Scrum,用户故事的另一个极其重要衍生物,可以直接用起来,这是我训练的Scrum团队能够真正玩好Scrum的重要原因。

    大部分的Scrum团队,都只是在玩Scrum过程的团队而已。

  • cucumber本身不复杂,网上资料很多,通常的问题是出在你们的系统架构上,要做到端到端的测试,对后端系统是有些小要求的。

    可以先看看我简书里面的那几个文章,基本上可以去动手尝试了。能搞定也就可以把钱省下来了,带着团队去撸串。

    微信可以找到我 edwardzhq

  • 看清楚,我简书里面的内容。不是单纯的从一个技术问题角度去处理。

    如果你没有Scrum中的用户故事与验收标准的概念和认识,那么你说的是对的,无需再讨论。

  • 面向想做自动化验收测试的人群。你这么说,否则某种程度上说明你们的UI测试人肉居多。或者浪费严重。

    https://www.jianshu.com/p/fd17c1bb6806

  • 追求过细的分工,才是一种伤害。

    我带的开发人员,分析得了需求,写的了故事,编的了代码,干得了测试(自动化测试,单元测试),部署得了生产(半自动化运维)。

  • 激动啥,这只是个噱头。难道包分配?

    能干活对福利好 匹配才是王道。

  • Elixir要不要?