I have said I would start a new dedicated testing thread. Well,err, this is it
To give everyone some background. I started hacking at Hugo for two reasons. Firstly I use hugo and I like it a lot. I much prefer it to the previous static website builder solution I was using (nanoc on ruby). Converting one of my sites to Hugo got me out of Ruby dependency hell, which I really appreciated. Go’s single binary approach is a big win. Secondly, I liked go. I’d used it previously to move an internal company web service from perl to go. As much as a proof of concept project as much as anything, So, I was looking for a go project to pitch in on And finally working on the the testing side of a project isn’t what I do for a day job. So that’s a big plus [For the curious, I’m actually a ScrumMaster in my day-to-day role],
When I asked Steve (@spf13) and Nate (@natefinch) what they were looking for in terms of help both suggested taking a look at testing. After that I just grabbed the code, ran the tests, and looked at the code coverage the tests were currently giving us. Then I just picked the one with the lowest figure an started adding tests. So it was dead easy to start helping out.
So, far I’ve focused on the hugolib/helpers module taking that from 25% coverage to 75%+. See my original testing thread for the details. Note; this is still WIP.
As much as there is a plan for all of this, what I think we should do is:
- Increase the test coverage generally across the whole project
- Then look to refactor the code and the tests
If we can achieve higher test coverage then that will enable as much refactoring as may be required. It makes adding new features easier, not only though better (refactored) code, but also because we’ll have a suite of regression tests. It’ll make bug hunting easier to and with a little luck the there will be fewer bugs going forward because of the tests.
So if you want to help out, post a message to the thread and we’ll see what we can all achieve.