今日推薦開源項目：《寫字 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/
