On Jul 8, 2010, at 20:24 , David Winslow wrote: > On 07/08/2010 09:30 AM, Sebastian Benthall wrote: >> As soon as possible, we should start requiring unit tests. Selenium has been >> brought up, which is great, but it's also got quite a learning curve and >> creating tests is somewhat time consuming. Personally, I'm familiar with >> TestAnotherWay, which is not great, but does its job well for JavaScript >> stuff - as long as there is not too much UI to test. >> >> In OpenLayers, unit test coverage used to grow with every ticket/patch. So >> one way to do it would be to start requiring unit tests at some point, and >> from that point on every change needs to be accompanied by unit tests. >> > Yes, unit tests are good. Let's break off a thread to discuss them > independently of commit policies. > > I think the last time we brought this up we decided that automated testing of > GUIs is hard and doubly so when those GUIs are made out of HTML and CSS and > being tested through Selenium. Additionally, GeoNode's JavaScript is mostly > GUIs built on top of frameworks that wrap data access and such, so there > wasn't a ton of perceived benefit, and we opted to rely on our weekly > deployments and keen-eyed development team to catch bugs instead of trying to > automate it. > > However, the other modules are stronger in terms of unit testing (except, > oops, the Django tests rely on consistent UUIDs across builds. Need to look > into that.) The GeoServer module has decent coverage (actually, we have a > coverage meter hooked up to it.... 74% line and 57% branch coverage) > > So, we could go ahead and institute this policy on the Python and Java > sections of the project if folks want. I could go on a coverage spree (man > do I love metrics) and get things up to a decent level of coverage on the > python side, and then yell at people when they bring it down. > > That does leave the question of which JavaScript framework to use. (And I > guess we can use a couple, if we want to go with Test.Anotherway for the less > graphical stuff and Selenium when macro recording seems like the way to go.) > > recap (I did ask a couple of questions in there :)) > * Should we start requiring tests in commits immediately for the portions of > the code with already-established test frameworks? > * If not, when? > * What test framework should we use for JavaScript? > * Any other thoughts on the matter?
I added these points to the etherpad (http://etherplans.org/geonode-commit-policy), with notes from myself. Regards, Andreas. -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers.
