![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jducoeur... there is something that is just soul-deep *satisfying* about finally getting a proper test harness working.
Up until now, Querki has basically been skating along with no proper automated testing. (Aside from the Markdown tests, which I inherited from the library I started with and have been maintaining as I evolve the language.) I've known from the beginning that that was a bad idea, but the system was evolving so fast for the first 9 months or so that I would have spent way too much time rewriting the tests over and over again to match it. And, frankly, I didn't know the Scala/Akka test tech very well, and had too many other things to learn first. So I've simply been hand-testing stuff as I went.
Those excuses ran out a while ago, though, and Alpha has demonstrated just how fast Code Rot has set in --![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
mindways found a *host* of dumb bugs, many of which would have been caught by proper test coverage.
So I've spent the past day or two finally writing the beginnings of a real test suite, beginning with the QL Language itself and the user-visible methods. I started out with a couple of methods that I'd been looking at and had noticed code smells -- I wrote some proper unit tests, confirmed the expected bugs, fixed the bugs and validated the fixes properly. Then, for good measure, I added a new feature (making it easier to use pictures in Querki) in a proper test-driven way: write the test, demonstrate that it fails, add the feature, and confirm that it now works.
Man, that feels good. I hadn't quite realized how deeply I'd internalized that particular Agile tenet until now: working without automated tests has been making me twitchy.
It's going to take a fair while to pay off all the test debt, even for just the back end. (The UI is much harder to test, and it going to have to wait longer.) But as of now, I'm putting correct procedures into place: when possible, bugs and fixes will be validated by unit tests, and I'll generally be shooting to add tests whenever I change code. With any luck, the time spent on that will be more than made up for in system stability...
Up until now, Querki has basically been skating along with no proper automated testing. (Aside from the Markdown tests, which I inherited from the library I started with and have been maintaining as I evolve the language.) I've known from the beginning that that was a bad idea, but the system was evolving so fast for the first 9 months or so that I would have spent way too much time rewriting the tests over and over again to match it. And, frankly, I didn't know the Scala/Akka test tech very well, and had too many other things to learn first. So I've simply been hand-testing stuff as I went.
Those excuses ran out a while ago, though, and Alpha has demonstrated just how fast Code Rot has set in --
mindways found a *host* of dumb bugs, many of which would have been caught by proper test coverage.So I've spent the past day or two finally writing the beginnings of a real test suite, beginning with the QL Language itself and the user-visible methods. I started out with a couple of methods that I'd been looking at and had noticed code smells -- I wrote some proper unit tests, confirmed the expected bugs, fixed the bugs and validated the fixes properly. Then, for good measure, I added a new feature (making it easier to use pictures in Querki) in a proper test-driven way: write the test, demonstrate that it fails, add the feature, and confirm that it now works.
Man, that feels good. I hadn't quite realized how deeply I'd internalized that particular Agile tenet until now: working without automated tests has been making me twitchy.
It's going to take a fair while to pay off all the test debt, even for just the back end. (The UI is much harder to test, and it going to have to wait longer.) But as of now, I'm putting correct procedures into place: when possible, bugs and fixes will be validated by unit tests, and I'll generally be shooting to add tests whenever I change code. With any luck, the time spent on that will be more than made up for in system stability...