[TFUI] Re: Stabilizing Sprint

jiri_lundak wrote:

> - We have tried JWebUnit and HttpUnit, but have unfortunately too
>   much proprietary JavaScript code in the web-pages and parsing fails)

Can you control which browser the users use?

(For a military project, gee I can't guess which browser they are probably
ordered to use...)

Create your browser as an Automation object, and drive it from the scripts.
Here's a snip of the relevant code:

    def startIE()
        $ie = WIN32OLE.new('InternetExplorer.Application')
    end

    def navigate(href)
        $ie.navigate2(href, NavNoReadFromCache | NavNoWriteToCache |
NavNoHistory)
        ieWait()
        $ie.Refresh()  #  ensure we really get the next page
        ieWait()
    end

    def surf(page)
        href = "http://#{TestSite}:#{TestPort}/#{page}"
        navigate(href)
    end

    def ieWait()
        while @ie.busy;  sleep(0) ;  end
        until @ie.readyState == READYSTATE_COMPLETE;   sleep(0);  end
    end

    def getNode(formID, inputID)
        formNode = @ie.document.forms(formID)
        return nil  if formNode.nil?
        inputNode = formNode.namedItem(inputID)
        return inputNode
    end

Now you can write test cases like this:

    def test_saveNewPage()

        name = "WikiSaveNewPage"
        zilchRemoteFile(wiki(name))
        surf("WikiSaveNewPage")

  #  this demonstrates that hitting a non-existent page brings up its editor

        saveButton = getNode('f', 'Save')
        assert_not_nil(saveButton)
        textArea = getNode('f', "text")
        assert_not_nil(textArea)
        sample = "what up?"
        textArea.innerText = sample
        saveButton.click()
        ieRefresh()
        assert remoteFileExists(wiki(name))
        assert_equal(sample, remoteRead(wiki(name)))
    end

That hits a page on my Wiki that does not exist, surfs IE to it, finds the
Save button, finds the Wiki <textarea>, writes "what up?" into it, clicks
the Save button, waits for the server hit, and checks that the new file
exists and contains my eloquence.

> - We try currently to overcome this by refactoring our XSL-Scripts
>   (unfortunately no refactoring tools for XSL I know of), removing
>   as much JavaScript as possible.

Yay! XSL!

But I wouldn't use a refactoring tool for such a tricky linguistic corner.
The point of a refactoring tool is it should analyze your code so well that
you never need to question if it worked properly. Mike Feathers, in /Working
Effectively with Legacy Code/, pointed out that a refactoring tool can
easily change the number of side-effects that a moved function produces. A
refactoring tool that can move client-side JavaScript into server-side XSL
will only become feasible long after it's irrelevant.

> - Unit-Test (not UI) are run on a daily basis (daily build and before
>   check-in)
>
> > After the fewest possible edits, do you run tests that reach out to
> other
> > places?
>
> - Yes, we try to integrate as often as possible

Sorry: What I mean is, when your fingers are on the keyboard, do you only
edit code for <3 minutes before each time you hit The Test Button. I don't
mean "frequent integration".

> - But because the tests still are by no means covering all the code
>   things can break anyway

As you remain aware of marginal test coverage, hitting the One Test Button
so frequently helps stabilize the process a _lot_.

Are you using Pair Programming?

> - Higher-level tests (UI) should help

Write high-level tests with a spreadsheet. GUI tests don't necessarily mean
high-level tests, but of course that always happens. My "test_saveNewPage()"
example is a high-level test, and thru a GUI.

-- 
  Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



------------------------ Yahoo! Groups Sponsor --------------------~--> 
$4.98 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/Q7_YsB/neXJAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~-> 

To unsubscribe, email:
TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org
 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/TestFirstUserInterfaces/

<*> To unsubscribe from this group, send an email to:
    TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/