Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Moving wiki_to_html into the templates
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Christopher Lenz  
View profile  
 More options Oct 25 2006, 9:54 am
From: Christopher Lenz <cml...@gmx.de>
Date: Wed, 25 Oct 2006 15:54:05 +0200
Local: Wed, Oct 25 2006 9:54 am
Subject: Re: [Trac-dev] Re: Moving wiki_to_html into the templates
Am 25.10.2006 um 12:48 schrieb Sergey:

> Christopher Lenz wrote:
>>> Consider also that JavaScript is not good when it comes to unit
>>> testing Web page generation. It's far easier to just test if  
>>> there's a
>>> reference to a stylesheet than to test that there's a javascript  
>>> that
>>> hopefully will insert this reference later.

>> That's not really "unit testing" now, is it ;-)

>> It's way easier to test this stuff at a lower level (using *actual*
>> unit tests), and then perform functional tests in the browser, either
>> manually, or using something like Selenium.

> Hi Chris!

> I'm not sure what do you mean here. If I were a macro writer, I'd
> probably have a unit test with a macro rendered on a page, and I'd use
> a few XPath expressions to make sure things are in place, such as
> stylesheet if there's one, macro output, etc. I didn't yet look at
> Trac's built-in macro tests, but I'd imagine that's how they would be
> organized. Or am I off-base here?

That's not a unit test, because you're also testing Trac, and are  
relying on the assumption that Trac doesn't shuffle stuff around so  
much that your test breaks without your Macro actually being broken  
itself.

If you want to *unit test* your macro, you'd test it in isolation  
from (most of) the rest of Trac. You'd simply call it directly with  
various parameters, and check the return value, as well as possible  
side effects on the request object. You can assert whether your macro  
added a stylesheet by checking whether it got added to the list in  
req.environ['trac.chrome.links']['stylesheet'].

Of course the kind of tests you mean are also useful, but they're  
generally referred to as "integration" or "functional"/"acceptance"  
tests. So this is mostly a terminology disagreement :-)

But even in integration tests, you'd probably call wiki_to_html() on  
wiki text that contains a reference to your macro, and you'd *still*  
use the technique explained above to check whether the stylesheet got  
added.

It's only when you move on to do functional tests where you might  
care about the difference about stylesheets added normally and those  
added via JS. But for functional tests, it's a good idea to use an  
actual browser (manually or automated, both are possible), which  
doesn't care how a stylesheet is added, both methods add <link>  
elements to the <head> in the DOM, and both result in the style rules  
in the stylesheet being applied.

Cheers,
Chris
--
Christopher Lenz
   cmlenz at gmx.de
   http://www.cmlenz.net/


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.