• 支持, 这是一家有技术追求的公司。 并且在帮助员工成长方便非常舍得投入。

  • Why a functional language? at 2019年07月31日

    Functional Programming? Don’t Even Bother, It’s a Silly Toy

    https://medium.com/better-programming/fp-toy-7f52ea0a947e

  • 支持

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

    你看看身边的 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