Testing tal cache states could be easier
Bug #586466 reported by
Curtis Hovey
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
Fix Released
|
High
|
Gary Poster | ||
Bug Description
There are cases where the cache age will vary based on the state of the object...long ages for complete object and short ages for object being worked. To verify that the cache age matches the state of the object, I inserted a comment.
It would be easier to verify the cache state of a chunk if the tal cache: directive automatically did it. I am only interested in this state for testing, so I only need a verification for the test runner env. I do not want comments in the production pages.
Related branches
lp:~gary/launchpad/bug586466
- Curtis Hovey (community): Approve
-
Diff: 161 lines (+46/-14)4 files modifiedlib/lp/registry/browser/tests/milestone-views.txt (+15/-6)
lib/lp/registry/templates/milestone-index.pt (+0/-2)
lib/lp/services/memcache/doc/tales-cache.txt (+22/-2)
lib/lp/services/memcache/tales.py (+9/-4)
Revision history for this message
| Gary Poster (gary) wrote | #1 |
| Changed in launchpad-foundations: | |
| status: | New → Triaged |
| importance: | Undecided → High |
| assignee: | nobody → Stuart Bishop (stub) |
| milestone: | none → 10.06 |
Revision history for this message
| Curtis Hovey (sinzui) wrote | #2 |
| Changed in launchpad-foundations: | |
| assignee: | Stuart Bishop (stub) → Gary Poster (gary) |
Revision history for this message
| Ursula Junque (ursinha) wrote Bug fixed by a commit | #3 |
| Changed in launchpad-foundations: | |
| status: | Triaged → Fix Committed |
| tags: | added: qa-needstesting |
| tags: |
added: qa-ok removed: qa-needstesting |
| Changed in launchpad-foundations: | |
| status: | Fix Committed → Fix Released |
To post a comment you must log in.
Implementation thought: it seems to me it would be easiest, and also a nice indication of the machinery working, if the test version of the tal component would show the comment with information about how long the snippet is to be cached when it renders a cached version. That would mean that the first time a view was rendered, the comment would not be present because the content was not cached; the second time, the comment would be present, because you would be seeing cached content. This could also encourage people to verify that cacheing is working as they expect, which wouldn't be all bad.