- This topic has 5 replies, 5 voices, and was last updated 9 years, 5 months ago by
.
-
Posts
-
Grunt has been a part of the core workflow for over a year now. Tests are being added on a more regular basis. We have built tools such as grunt-css-janus and grunt-patch-wordpress.
But we shouldn’t rest there. What other tools can we build or add to improve contributions and make life easy for contributors? How can we get developers paying more attention to our unit tests failing?
+1, I love me some dev tooling! Lots of room for improvement, both within and without what we have now.
This could also serve as a venue to discuss potential future improvements to the scripts and styles included in, or built with, WordPress core, since any modularization of those would entail additional tooling
PHP_CodeSniffer WordPress Coding Standards for Core. We’ve got a script prepared which selectively applies rules to the diff of a new commit, which would help slowly clean up the Core’s codebase as more and more code gets touched, but ignore code in a file that is not part of the patch.
Tenon.IO is for automated accessibility testing, it is still in a private beta but will become an open public beta this Wednesday, though you can test anything right now via http://tenon.io/index.html#testnow with a URL or direct HTML copy and paste.
A Grunt tool I am lead to believe will be made available, and for some background on Tenon IO and their plans the following articles should help:
http://www.karlgroves.com/category/accessibility-testing/The accessibility team, of which Karl Groves is a contributor touched on it earlier this year:
I’ve been in the private beta of Tenon.IO since it kicked off and it is extremely helpful to say the least, bbPress has always tried to be accessible, though keeping up with “everything” accessibility is not easy, we’ve a few patches ready to add to bbPress based off of this testing here.
- The forum ‘Community Summit Discussion Topics’ is closed to new topics and replies.