Previous Entry Share Next Entry
Release 1.3.6
querki
jducoeur wrote in querki_project
This week's release has some user-visible stuff in it, largely bug fixes, as listed below. But the major new change is internal: Querki finally has a functional-testing harness.

Automated testing is crucial to software development, trebly so for a small company without the resources to do testing manually. It comes in two major flavors. On the one hand, there's unit testing -- tests that exercise a specific little bit of the code fairly thoroughly, to make sure it's working right. We've had unit tests for certain sections for a long time -- in particular, most QL functions are pretty thoroughly tested, and those tests get checked frequently.

The thing is, unit testing is good for testing the individual little bits -- but Querki is *mostly* about how those bits work together. Indeed, most bugs that have come up in the past year haven't had anything to do with the well-tested part of the system; instead, they've been problems with how the back and front ends are working together. Each individual piece is working correctly, by its own lights; the problems come in the nuances of how those bits work together. Unit testing is bad at catching such things.

That's where functional testing comes in. Instead of tests that exercise little bits of code, a functional-test harness actually runs Querki itself, and puts it through its paces. That's one reason why I've only gotten around to it now: it's a *lot* of work to write a good functional-test harness. The bugs listed below were mostly pretty similar in dealing with them: in each case, it took me something like three minutes to figure out what was going on, a line or two of code to fix it -- and eight hours of work to enhance the functional-test system to the point where it could *prove* that this was fixed.

It's far from done -- Querki is huge and complex, which means the test system is also going to wind up huge and complex. But I'm finally getting to the point where I can write a test that reads kind of like a description of the steps, and it's taking less and less time to deal with each.

Going forward, this *will* slow down bug-fixing for Querki a bit: I'm starting to follow the discipline of writing a regression test for each bug -- an automated test proving that this bug is fixed, which will raise a red flag if it breaks again. But it should gradually reduce the number of bugs in Querki, as more and more of them get caught by these tests instead of getting released.

For the most part, though, this process will be invisible to you unless you enjoy digging into the actual HTML of the page. (Which is gaining lots more ids and stuff, to make it easier for the Selenium-based test harness to work with it.)

Anyway, on to the changes that you can actually see...

Enhancements

Major enhancements to _linkButton(): The _linkButton() function has been around for a long time -- it takes a Thing or a URL, and produces a button with a text label. It's been useful but limited -- I wound up also needing _iconButton() (to display a button that shows an icon) and _mixedButton() (which shows an icon *and* a label), and those have been annoying me for a long time.

So now that we have the ability to define optional parameters to functions, I've completely rewritten _linkButton() to absorb all of these functions into one. You can now choose to specify a label and/or an icon for your button; you can also specify a tooltip to display when hovering over the button, as well as the HTML id to assign to it. (The latter was actually the motivation -- I needed that id for the functional tests, and decided to deal with the whole problem while I was at it.) The result is a much more generally-useful gadget, which I hope you'll find helpful.


Added the _searchInput function: this was a request from mindways (which serves as a reminder: folks who actually *use* Querki at this stage of the game get a lot of influence in shaping what goes into it). He's building a Space that needs to be mobile-friendly, and may be pretty Search-centric. Problem is, on a smartphone the Search input box gets collapsed into a menu, and he wants it more front-and-center.

So I've added a new _searchInput function, which simply inserts a Search box wherever it is used. It's simplistic, and will likely grow with time, but for now it lets you put Search into your workflow where you need it.

Bugfixes

You can now edit text in lists on a touch screen: closely related to the fix we made the other week for the Advanced Editor, rearranging list items now requires that you drag using the visible drag handles -- you can't just drag anywhere in the list element. We'd previously allowed you to drag from anywhere, but that was screwing up editing on touch screens.


Apostrophes and other HTML entities show up correctly in the page title: if you had a Thing named, say, "I don't work", and you looked at the browser tab for its page, it would show up as "I don't work". This is now fixed.


The title of Tag Pages now works again: this was a recent regression -- if you clicked on a Tag, the title of its page would show ".-1". This is now fixed. (And tested, to make sure it doesn't happen again.)


The Done button in the Advanced Editor now works if you change the name: previously, if you were in the Advanced Editor / Model Designer, and you changed the Name of the Thing, clicking the "Done" button would mysteriously go to a non-existent Tag's page, with the old Name. This was because the Done button was going to a page based on the Name, which was being calculated when you started editing -- so when you changed the Name, the "Done" button was now going to a non-existent page. For now, this is fixed by "Done" going to the Thing's page by OID instead, since the OID never changes. We might eventually make this more subtle (recomputing the Done button if the Name changes), but for now, this should work fine.


You can now use ____ in the Page Header for unreified Tags: this one's subtle. (Also discovered by mindways.) If you have a Tag, and you want to show it with a different header from the default, how do you do that? You specify a Page Header in the Model that the Tag is Restricted To. How do you display the Tag's name *inside* that header? You use ____, the usual QText for "put the received value here". Problem is, it didn't work -- it would show, literally, "Some HTML". (Yes, there's a reason for that, but it's not what you want to see here.) This now works correctly: ____ in the Page Header for a Tag now shows the Tag itself.
Tags:

?

Log in

No account? Create an account