My latest project is something I call “LJ Content Sieve”: a Greasemonkey script to filter out content on one’s Livejournal views based on nearly any attribute of a post or comment.<\/p>\n
However, Livejournal is very customizable. It has 31 different “layouts”, each of which can then be further “themed” by application of CSS. This means that a user viewing a given journal, community, or single post, at a given time, may receive an HTML document containing any of 31 different DOM structures.<\/p>\n
This means that finding a post’s author, or title, or even just a single post or comment, is not a straightforward process. I’ve set myself up a Ruby script that downloaded my “friends” view, a representative entry with lots of comments, and my own journal view, thus giving me a set of 93 fixtures that I can test against. The Ruby script also tweaked each fixture in the process of spooling it to my hard drive, by adding the proper calls to JSUnit files.<\/p>\n
At the end of each document’s <head> element, there’s a call to Then all the “friends” page fixtures get an Finally, each fixture page gets a test file based on its layout: the “3 Column” layout gets Without test-driven development and automated testing to ensure that each layout and page-type is being handled properly, I don’t think this project would be manageable at all.<\/p>\n","protected":false},"excerpt":{"rendered":" My latest project is something I call “LJ Content Sieve”: a Greasemonkey script to filter out content on one’s Livejournal views based on nearly any attribute of a post or comment. However, Livejournal is very customizable. It has 31 different “layouts”, each of which can then be further “themed” by application of CSS. This means […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[37,7,38,6],"_links":{"self":[{"href":"https:\/\/kagan.mactane.org\/blog\/wp-json\/wp\/v2\/posts\/78"}],"collection":[{"href":"https:\/\/kagan.mactane.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kagan.mactane.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kagan.mactane.org\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/kagan.mactane.org\/blog\/wp-json\/wp\/v2\/comments?post=78"}],"version-history":[{"count":1,"href":"https:\/\/kagan.mactane.org\/blog\/wp-json\/wp\/v2\/posts\/78\/revisions"}],"predecessor-version":[{"id":79,"href":"https:\/\/kagan.mactane.org\/blog\/wp-json\/wp\/v2\/posts\/78\/revisions\/79"}],"wp:attachment":[{"href":"https:\/\/kagan.mactane.org\/blog\/wp-json\/wp\/v2\/media?parent=78"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kagan.mactane.org\/blog\/wp-json\/wp\/v2\/categories?post=78"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kagan.mactane.org\/blog\/wp-json\/wp\/v2\/tags?post=78"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}jsUnitCore.js<\/code>. Then, at the end of each <body>, I add a call to the lj-content-sieve.user.js<\/code> script itself, as well as a set of test files that depends on which fixture this is. Every fixture gets an ljcs-global-tests.js<\/code> call added to it — that file contains tests that should work anywhere, regardless of what sort of page you’re on.<\/p>\nljcs-friends-tests.js<\/code> file, which tests operations that should happen on every friends page. For example, determining which entries need to be deleted. (In contrast, single-entry pages get ljcs-entry-tests.js<\/code>, and the page from my own journal — which stands in for a view of a community — gets ljcs-self-tests.js<\/code>.)<\/p>\nljcs-3 Column-tests.js<\/code>, while “Cuteness Attack” gets ljcs-Cuteness Attack-tests.js<\/code>. (Hey, I didn’t write or name the layouts; I just have to make sure LJCS works with all of ’em.) These files will test that the actual DOM manipulations work properly.<\/p>\n