今日推荐开源项目：《写字 hanzi-writer》
今日推荐英文原文：《Testing is not a first class citizen.》
今日推荐开源项目：《写字 hanzi-writer》传送门：项目链接
推荐理由：这个项目是一个关于汉字笔画顺序的 JS 库——包括展示正确的书写动画以及对用户的输入笔画进行识别来确认书写顺序是否有误两个方面。很容易想到它可以作为汉字书写教学网站的核心来使用，不过没准也可以用于一些特定主题网站的验证码上，顺便还能防止敲键盘太多忘记如何写字的副作用。
今日推荐英文原文：《Testing is not a first class citizen.》作者：James O'Toole
原文链接：https://medium.com/nomoss/testing-is-not-a-first-class-citizen-90088f0e4245
推荐理由：尽管测试已经成为了开发的一环，但是大部分语言依然没有太多面向测试的部分
Testing is not a first class citizen.
Here’s a fun list; programming languages which don’t have unit testing built into their standard compiler/runtime tool-sets or standard libraries.- Java/JDK (It includes 33 other binaries and tools however. ?)
- PHP (PHP Unit, like JUnit is a framework and does not come with the language)
- Node/JS — Nope. Most active language and testing is an after thought. —
- C++ (No standard or standard library tooling)
- Python has a in its standard library unittest API, though it’s a bit limited.
- Golang has go test, built in to the compiler tool-chain that’s quite nice. Has no assert statement though which annoys me bit
- Rust has various macros to assist in testing and it is built into cargo
- Ruby has a Test standard library package.
So What?
1.Its not in the design of the language, it’s not going to be in the ethos of your developers, your community and your projects. If it’s an afterthought to the language and it’s creators, why should we expect it to be different for the frameworks that drive the application development. Why would we expect libraries to give it the same duty of care in considering how their implementations will fit into peoples testing framework, particularly if you can’t judge which of their community tool-sets they’ll be using. This is where not even having things like assert in your language and basic constructs for people to test the code that they write will lead to a trickle down effect on everything that touches it.2.The stopgap solutions have deficiencies and approaches which are come up by community standards, this trickles into the frameworks and leads people to steer away from testing their code. NodeJS not having a testing binary means we rely on fragile community tools. JUnit might be a defecto standard, but it’s still a dependency, not a first class citizen. This means every project will include extra tools for their specific needs, will bring in their own specific approaches to solve mocks and dependency injection. Learn one framework and you’ll need to learn a different set of testing tools because the standard is not defined.
3.Affordances in design intent create better results for the people that have to use them. Put a shoe rack at the front of your house and people will leave their shoes there. I’m talking about creating simple affordances to make it simple to do the right thing. Rust built it well into its language, and it begot rspec which became the golden standard for BDD tests. My favourite thing about Golang is the SRCFILE_test.go pattern which encourages you to write tests along side your source files. Not hidden in away in another folder but first class to your own code base. If your tests files are treated as just as essential to your source code then it will be treated as such. Make it easy and people will do it, and consistently. Your code should be as easy to create to the standards of the Standard Library, Go is the only language that’s made that possible in my experience.
“But we can just do what the right anyway”. Yes, we can. Of course, I believe that strongly teams and individuals can create, discuss and adapt standards to do things better. However, every month programming languages continue to keep getting more features, more things to optimise and increase better ways of doing things, but they’re ignoring blatant gaps. Why is there still no official testing binary in NodeJS is beyond me, and projects would have gone in much better directions if there was. Instead people have relied on whatever the testing tool is flavour of the month and ready to become apart of your growing NPM dependency debt.
There is endless debate and great reading on different ways in which testing approaches can benefit how you write your code and tests; but I wanted to express my frustration. Good design in tools can create better results, and I feel like with every passing year of my dev life I love Golang more and more the choices the team made in its creation.
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
