>     Posted by: "Carlos Ble" ble.jurado@... carlosble

> I've just read the wikipedia entry for Presenter First patter:
> http://en.wikipedia.org/wiki/Presenter_First
>
> To read about TDD there is nice but I don't see why TDD is related to
> Presenter First more than MVC or MVP.

WikiPedia might possibly be ... (mumble) ... incorrect. It has been known to
happen before. It's certainly just an aberration.

> They are all basically the same. One can test drive a controller too.
> I don't remeber hearing about TDD in the
> presenter first shows with Ron Jacobs.

If "presenter first" is derived from "Humble Dialog Box", it's not cannon
(meaning "officially correct"). It's just a really good idea, sometimes.

> A paragraph within the article says:
>     "A customer will generally explain features in terms of 'when'
> statements - for example, "When I click the 'save' button then the
> file should be saved and the unsaved file warning should disappear."

To TDD that, write a test that changes a view's "modified" flag, possibly by
modifying its document, then assert that the view activates the "modified" icon.
If, for example, it highlights the Save button, then the test can assert that
the code selected the highlit icon behind that button.

Then a related test can modify the file, simulate a click to the Save button
(usually by calling the handler method that Save would have called). Then the
test asserts the file on disk has changed (yes, sometimes tests detect
filesystem side-effects!). Then the test checks that the button changed its
icon, and that the "modified" flag is down.

> This is wrong again to me. Customers should not decide how that UI
> works but what they need. User stories should not
> be attached to user interfaces I think.

Use Cases should not attach to user interfaces. The early User Stories are like
Use Cases, because the Onsite Customer is not a real Usability Designer, and
should not play one on TV.

Later User Stories will easily refer to changes to a UI that already exists, so
they do not work like Use Cases.

--
    Phlip

John Overbaugh wrote:

> Presentation layer: we have a lot of cookie, session, view state and
> Ajax code in our presentation level. Apparently this is rather brittle
> code which means we've frequently broken stuff in the past. My dev and I
> have been discussing this, and the impact of a cookie or session change
> has been far-reaching and surprising. So we're wondering if there's a
> way to cover this stuff in a unit test - after all, this is code written
> by developer, it ought to be unit tested but that's the challenge we're
> grappling with. The challenge, of course, is that we're talking about
> unit tests which require interaction with a web server.

Here's a metaphor - the Golden Spike at Promontory Point, Utah, where the Union
Pacific and Central Pacific railways met for our first intercontinental
railroad.

A test through the browser is like driving a train all the way from St Louis to
San Fransisco.

Two unit tests are like driving all the way from one city to the golden spike.

To unit test, you don't need to test that a variable went into a session, went
into a cookie, came out in an action, went into JavaScript, went into Ajax, and
went into the browser.

You need to unit test each of those steps - even sinking as low as using
assert_match to spot-check that a variable showed up in some string.

Yet each unit test must reach just a little into the next layer. Otherwise, your
tests might not detect if you have two railroads that don't meet at Promontory
Point...

--
    Phlip

Kaleb Pederson wrote:

> I'm a bit out of my realm as I'm usually strictly backend, but I'm going to
delving into things like this very soon so I've been paying attention to these
topics for a while now.
>
> Still, I'm quite curious exactly what you mean by unit testing the
presentation layer?
>
> Does that imply that you're verifying what the HTML elements, CSS,and Ajax
results are for given calls to the backend?  If so, why not test it at the
backend level?

To add a new feature, you should generally add it at the business layer first.
The goal will be that anything a user can do to the View, a unit test can do,
generally the same way, to the business layer.

In the view, don't test the shiny things. Test that your template system has
injected the correct variables. The tests help preserve these behaviors when you
upgrade & refactor, including when you change the shiny things.

> If you're testing mainly what's going on at the front end, it seems like you
could use pure HTML / Javascript to confirm that things act correctly using some
mocked calls to the backend. I guess you could call it a mocked server, but I'm
essentially thinking of a separate facade / interface that doesn't bother with
round-trip calls to a server (even localhost).

JS only works correctly inside a browser. Tests should run under 10 seconds,
from an unattended script. Browsers are not well tuned to be test targets.

Tests on JS should detect that the template systems have injected the correct
data into them. I do this by parsing the JS into a lexical analysis, using
"rkelly", then querying into the resulting parse tree to detect the variables.

> Of course, this doesn't take into account the rendering and cross-browser
compatibility issues, but that's where Selenium Wati(r|n) and friends come into
play.

TDD is not QA testing. At TDD time, we don't need to test that JS commands a
browser correctly, we need to test that our business logic has commanded the JS
correctly. Whether the JS works or not is a different issue.

If the tests constrain JS that does not work, only manual testing will detect a
problem. Programmers should manually test before deploying. If you then upgrade
the JS so it works, the tests should now constrain JS that works. This improves
the odds you don't break the JS when you refactor something.

The systems like Watir that test through the browser are very important, but...

They have provided an entire generation of programmers with an easy entry into
any kind of testing at all. Some projects use no unit tests whatsoever, and they
slowly and painstakingly test everything - including the business logic -
through the View. Some projects have unit tests on the business layers and not
the View.

Of course these tests are better than nothing. Yet in the test food pyramid...

    http://c2.com/cgi/wiki?TestFoodPyramid

...a diet of only Watir tests would be like living only on ice cream and beer.
It's fun at first, then the malnutrition begins...

--
    Phlip

> Re: Can ASP render a page back as a string. Absolutely! Its
> call Response.Write, just pipe it out to whatever channel
> you like :)

Could anyone here who's familiar with both ASP's Response.Write, and with
Rails's ActionController::TestCase's get() method, write a little pseudocode
here showing how to write that method into the lightest possible Nunit test
case?

(Allow me to slag on ASP anyway, but I'm only familiar with its VB Classic
incarnation, >1 decade ago...;)

--
    Phlip

Re: Can ASP render a page back as a string.
Absolutely! Its call Response.Write, just pipe it out to whatever channel you
like :)

Regards,

Miguel de Sousa




________________________________
From: Phlip <phlip2005@...>
To: agile-testing@yahoogroups.com; testfirstuserinterfaces@yahoogroups.com
Sent: Friday, 12 June, 2009 13:48:10
Subject: [TFUI] Re: [agile-testing] Unit Testing the Presentation Layer





John Overbaugh wrote:

> I'm not sure this answers my question. What I'm looking for are 1) best
> practices around unit testing the presentation layer

Unit testing the presentation layer should treat the test targets the same as
any other layer would test them. In web programming, a web page is a big string.
If you had a business-layer module that produced a big string, you would _unit_
test it by parsing the string back using the same tools as generated it.

Testing thru-the-server AND thru-the-browser is slow and fragile. Only do it
_after_ you can TDD the source directly, because that's where most development
should happen.

> and 2) ideas around
> headless testing within the presentation layer (if it's at all
> possible). I am quite familiar with Selenium, WatiN, etc.and how to use
> them even against Ajax (which is, I believe, what your offering). I'm
> trying to take it to the next level and create a good, reliable,
> headless unit test for my dev team (if it can be done).

Again: Can ASP render a page back as a string, ready to be parsed? If not, then
ask MS why. The answer is probably inexcusable vendor lock-in.

--
Phlip






[Non-text portions of this message have been removed]

John Overbaugh wrote:

> I'm not sure this answers my question. What I'm looking for are 1) best
> practices around unit testing the presentation layer

Unit testing the presentation layer should treat the test targets the same as
any other layer would test them. In web programming, a web page is a big string.
If you had a business-layer module that produced a big string, you would _unit_
test it by parsing the string back using the same tools as generated it.

Testing thru-the-server AND thru-the-browser is slow and fragile. Only do it
_after_ you can TDD the source directly, because that's where most development
should happen.

  > and 2) ideas around
> headless testing within the presentation layer (if it's at all
> possible). I am quite familiar with Selenium, WatiN, etc.and how to use
> them even against Ajax (which is, I believe, what your offering). I'm
> trying to take it to the next level and create a good, reliable,
> headless unit test for my dev team (if it can be done).

Again: Can ASP render a page back as a string, ready to be parsed? If not, then
ask MS why. The answer is probably inexcusable vendor lock-in.

--
    Phlip

John Overbaugh wrote:

> One of the challenges we are facing at Medicity is implementing unit
> tests which validate the logic in various layers. Right now, for
> instance, a lot of logic is in stored procedures and our code just
> bubbles that data up. We're working on refactoring that logic into the
> business logic layer, where it'll be more easily unit tested. Another
> problem we face, however, is unit testing the work done in the
> presentation layer. We have implemented various versions of
> .NET/ASP/ASPX and Ajax, so our presentation layer is chock-full of
> session management, some data manipulation/event handling, view state
> management and other Ajax functionality. I've been digging around and I
> have found a lot of stuff on the Web proving a lot of companies are
> grappling with this issue, but no really solid suggestions.

Will ASP allow you to cook a web page without sending it over the wire?

If you Mock The Server, you can then test - even TDD - by writing assertions
that parse the HTML back and extract the inserted data.

You are not testing that the page renders correctly. (That's okay, because you
are not writing the web browser itself.) You are affirming that when you
refactor the page will continue to render the same way it did before.

> I haven't looked at our code yet, but apparently there was some
> investigation into integrating Webaii as a headless test running in
> Cruise Control. Right now, I'd be happy to just have tests running on
> developer machines prior to check-in!
>
> Does anyone have a good solution they can talk about? What are some
> directions I can take to develop either a headless or a low-impact unit
> test framework, which can validate the presentation layer when it's a
> very dynamic layer?

Some web stacks don't let you Mock The Server, because they don't want you to
replace >cough< IIS with some other server. These corporate games should never
hold projects hostile...

--
    Phlip

Colin Law wrote:

> I think I have not explained myself adequately.  I have no problem with
> points 1 and 2 - the test and the implementation for the action invoked
> when the remote call is made.  It is point 3 that is the problem.  How
> do I write the test for the link_to_remote placement unless I know the
> form of the html that link_to_remote generates?

Here is a bit of hemming and hawing, while I work on projects other than
assert_xhtml and assert_rjs_ (as seen at http://c2.com/cgi/wiki?AssertXhtml )

TDD (aka BDD) works best on greenfield projects - ideally on platforms which
were themselves invented via TDD. Such projects will have assertions matching
each feature, ready to use. You simply alternate between writing assertions and
writing code statements.

  > I know the URL but not
> how the div and url appear within the Ajax.Updater javascript call.  In
> principle I do not even know that there is an Ajax.Updater call, nor
> whether I need to check any of the other parameters of the call.

When TDDing into a legacy system, especially a View, expect to cheat early and
often.

Write the test up until the point where you have no assertion, then fudge it.
Assert that your <a onclick> matches 42, for example.

Write the code you want, get the assertion to fail, and look at the diagnostic.
Copy its relevant details into your assert_match, and keep going. A change in
the RJS library might someday break your assertion; you don't care.

The _next_ time you TDD an <a onclick>, clone that assertion and upgrade it. You
will soon discover an application-specific assertion pattern which might work
for all Ajax in the world, but will tolerably propel your own project.

My assert_rjs_ is teetering on the brink of doing this:

    a = assert_xhtml{|x| x.a.my_id! }
    assert_rjs_ a[:onclick], :remote_function, :url => { :action => 'yo' }

However, these days I am shamelessly earning money instead of working on it.
Sorry! (-:

--
    Phlip
    http://flea.sourceforge.net/resume.html

Lisa Crispin wrote:

> We definitely want to do these investigative efforts. But I still feel
> examples are a good way to start. What have other folks found on their
> projects?

I have to confess a low rate of adoption for my assert_xpath project, to
unit-test raw HTML. As a computer scientist and a DSL-zealot, I _like_ writing
inhumanly elaborate queries, like '//fieldset[ following-sibling::input[ @name =
"etc" ] ]'.

Someone on the net recently challenged a forum to write an assertion like that,
but in this format, and I did it:

    assert_xhtml do
      form @action do
        fieldset do
          label 'first name'
          input :name => 'etc'
        end
      end
    end

Easier to read, huh? The HTML element names are all raw Ruby; they call
method_missing(), to convert into XPath expressions like that, on the fly.

That forum was the RSpec mailing list, and this leads to an interesting
observation. RSpec, and Behavior Driven Development, were _supposed_ to be about
the customer tests. Yet these days the general Ruby on Rails community now
considers TDD (and the test/unit library) to be OLD SCHOOL!

All the new, cool projects use RSpec. It appears that programmers like to
specify their designs by example, too.

Here's that assertion's RSpec version:

    @response.body.should be_html_with{
      form @action do
        fieldset do
          label 'first name'
          input :name => 'etc'
        end
      end
    }

Like all good examples, those assertions skip over irrelevant details, such as
intervening <table>, <div>, <li> tags, or whatever.

(Those of you with Ruby can try those by grabbing the assert2 gem; then calling
require 'assert2/xhtml'.)

--
    Phlip
    http://www.zeroplayer.com/

Hendrik Belitz wrote:

> Although I agree with that, I think that unit tests are not the answer
> to detect UI faults. Indeed, Integration and acceptance tests provide
> such capabilities in a much more usable manner, without significantly
> loosing test coverage.

Tests also help you go faster, not just detect faults. Consider this example:

    <div style='color: red'>
      <div style='background-color: green'>

To assert that your resulting color scheme is nauseating, you might just test
you have a red div followed by one with a green background.

You do not render that - physically, or virtually - then assert the contained
text appears red-on-green. You just assert you have two divs.

Now suppose a careless programmer changed their order:

    <div style='background-color: green'>
      <div style='color: red'>

The browser would render that correctly, and the user would see no bug. But the
test would fail - it is "hyperactive" - and that is a Good Thing. The test
allowed programmers to rapidly develop, knowing that if any test fails
unexpectedly they have the option to revert, without even debugging to figure
out _why_ the tests failed.

You can't go fast unless your car has brakes and your road has traffic lights!

--
    Phlip
    http://www.zeroplayer.com/

Jason Citron wrote:
>
> For structural HTML testing you should check out assert_select. It comes
> with Rails 2.0.
>
> Useful for testing XML too.

Try writing the equivalent of my assertion with it.

I suspect you can't, because it can't constrain the element order.

And the rest would be extremely verbose...

--
    Phlip

For structural HTML testing you should check out assert_select. It comes
with Rails 2.0.

Useful for testing XML too.

http://api.rubyonrails.org/classes/ActionController/Assertions/SelectorAssertion\
s.html

On Wed, Mar 11, 2009 at 10:27 PM, Phlip <phlip2005@...> wrote:

>   extremists:
>
> HTML is easy to test and hard to test well. A unit test must intercept and
> parse
> it, hopefully _before_ it goes thru a web server.
>
> I just wrote an assertion which turns that problem on its head. Instead of
> asserting how to parse that HTML, we will assert how to build an example of
> HTML
> that the production HTML must match.
>
> This post is the high-level, language-agnostic, overview of these
> announcement
> posts:
>
> http://www.ruby-forum.com/topic/181145#792950
>
> Here's the example:
>
> user = users(:Moses)
> get :edit_user, :id => user.id # fetches a web page
>
> assert_xhtml do
>
> form :action => '/users' do
> fieldset do
> legend 'Personal Information'
> label 'First name'
> input :type => 'text',
> :name => 'user[first_name]'
> :value => user.first_name
> end
> end
>
> end
>
> That's all. Inside the assertion's block, you declare the HTML you want,
> using a
> Builder notation. (Nokogiri, in Ruby's case.)
>
> The assertion skips over any intervening elements, such as <ul>, <table>,
> etc,
> that the block did not build. In the above example, <fieldset> only needs
> to
> appear somewhere inside the <form> - not necessarily its first element. But
>
> those <label> and <input> fields must appear somewhere inside that
> <fieldset>,
> and in the given order!
>
> To create this assertion in your language, start with your nearest HTML
> builder.
> Allow the user-programmer to build an example, then traverse its DOM, and
> convert each item into an XPath seeking that item in the production HTML.
> Declare a match if all the specified attributes match, and if most of the
> text
> matches - disregarding blanks.
>
> Then, for each match, recursively match each built child element, applying
> its
> XPath relative to the current node in the production HTML's DOM.
>
> When you find a fault, build an error message by rendering the current
> nodes to
> HTML, and return this out of your loop statements. This Gist explicates the
>
> algorithm:
>
> http://gist.github.com/76136
>
> The algorithm essentially matches two trees, depth-first and in-order. The
> example HTML must be a subset of the production HTML.
>
> If you survive all that recursing and matching then your assertion passes.
> You
> verified a huge number of details, using extremely lean code, and you
> ignored
> many more details, allowing them to change freely as you upgrade your
> website.
>
> --
> Phlip
> http://www.zeroplayer.com/
>
>


[Non-text portions of this message have been removed]

extremists:

HTML is easy to test and hard to test well. A unit test must intercept and parse
it, hopefully _before_ it goes thru a web server.

I just wrote an assertion which turns that problem on its head. Instead of
asserting how to parse that HTML, we will assert how to build an example of HTML
that the production HTML must match.

This post is the high-level, language-agnostic, overview of these announcement
posts:

    http://www.ruby-forum.com/topic/181145#792950

Here's the example:

       user = users(:Moses)
       get :edit_user, :id => user.id   #  fetches a web page

       assert_xhtml do

         form :action => '/users' do
           fieldset do
             legend 'Personal Information'
             label 'First name'
             input :type => 'text',
                   :name => 'user[first_name]'
                   :value => user.first_name
           end
         end

       end

That's all. Inside the assertion's block, you declare the HTML you want, using a
Builder notation. (Nokogiri, in Ruby's case.)

The assertion skips over any intervening elements, such as <ul>, <table>, etc,
that the block did not build. In the above example, <fieldset> only needs to
appear somewhere inside the <form> - not necessarily its first element. But
those <label> and <input> fields must appear somewhere inside that <fieldset>,
and in the given order!

To create this assertion in your language, start with your nearest HTML builder.
Allow the user-programmer to build an example, then traverse its DOM, and
convert each item into an XPath seeking that item in the production HTML.
Declare a match if all the specified attributes match, and if most of the text
matches - disregarding blanks.

Then, for each match, recursively match each built child element, applying its
XPath relative to the current node in the production HTML's DOM.

When you find a fault, build an error message by rendering the current nodes to
HTML, and return this out of your loop statements. This Gist explicates the
algorithm:

     http://gist.github.com/76136

The algorithm essentially matches two trees, depth-first and in-order. The
example HTML must be a subset of the production HTML.

If you survive all that recursing and matching then your assertion passes. You
verified a huge number of details, using extremely lean code, and you ignored
many more details, allowing them to change freely as you upgrade your website.

--
    Phlip
    http://www.zeroplayer.com/

Zach Dennis wrote:

  >> response.body.should be_xml_with do
  >>  form :action => '/users' do
  >>    fieldset do
  >>      legend "Personal Information"
  >>      label "First name"
  >>      input :type => 'text', :name => 'user[first_name]'
  >>    end
  >>  end
  >> end

  > I like this a lot.

Boom: http://gist.github.com/76136

    it 'should have a form with a fieldset' do
      render '/users/new'

      response.body.should be_html_with{
        form :action => '/users' do
          fieldset do
            legend 'Personal Information'
            label 'First name'
            input :type => 'text', :name => 'user[first_name]'
          end
        end
      }
    end

I think I never got around to writing that because I just always assumed someone
already had. I have to watch that about myself!

Only one feature is missing: At fault time, the matcher naturally prints out a
diagnostic containing two snips of HTML - the specification's reference, and
your page's sample. (Both, of course, are restricted to the fault's context -
not the whole page.) But...

The samples are not indented! The specification's reference is all run together,
and your page's sample is (unfortunately!) exactly the way your View system
generated it. I have a question out to Nokogiri about this...

--
    Phlip
    http://www.zeroplayer.com/

Alan,

> The thing is, tags and articles represent an undirected cyclic graph, not a
tree.
> A mind map is supposed to be a tree.

I think the original Buzan meaning wasn´t so limited as this. Basically, it´s a
2-D representation of something in your mind. So, it can be a whatever you can
draw...

John D.

>From: Phlip <phlip2005@...>
>
>Alan Baljeu wrote:
>
>> The thing is, tags and articles represent an undirected cyclic graph,
>> not a tree.
>> A mind map is supposed to be a tree.
>
>Read the post!

Good idea! [reads] Okay, done.

So you're building a minimum spanning tree of articles, using
tag-difference as the metric, and setting the current article as
root.

You're right my impression from the initial picture mislead me.
So why is there a cycle there?  Oh there isn't, it just looked
that way from how the graph got laid out.

Sorry about that.


       __________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!

http://www.flickr.com/gift/

Alan Baljeu wrote:

> The thing is, tags and articles represent an undirected cyclic graph,
> not a tree.
> A mind map is supposed to be a tree.

Read the post!

Phlip wrote:
>I myself quarrel with the use of "Merb" in the title. There's almost no Merb in
>the content, and I only forced myself to use it because I personally needed to
>learn it before it devours Rails.

So if you called it "Merb mind map" for alliteration, but Merb, mind, and map
are all misused words.... :-)

>> Did Crispin and Gregory use this term?
>If they did, would I be off the hook? That's "appeal to authority", you know...

I just want to know if the problem is bigger than just one blog post.

>- I auditioned some GraphViz tools that display radial links out
>from a root, but I couldn't briefly get them to look right
>in a bloggable format

The thing is, tags and articles represent an undirected cyclic graph, not a
tree.
A mind map is supposed to be a tree.

>The "mind map" I learned in the 1970s might have gone under a different name. I
>don't recall it - obviously. It's a classroom note taking technique looking
like
>this:
>....
Ascii doesn't do it justice I think :-)  Yes it is primarily a note taking
technique.
It's also a medium for thinking and brainstorming.

-----
Thinking about the tag graph:

If you have one article with 4 tags, doesn't that lead to 4 interconnected links
between those tags?  What do you do about that?

Alan


       __________________________________________________________________
Get a sneak peak at messages with a handy reading pane with All new Yahoo! Mail:
http://ca.promos.yahoo.com/newmail/overview2/

Alan Baljeu wrote:

> Nevertheless, I must quarrel with your use of the term mind-map.

It begins with M, making the title alliterative.

I myself quarrel with the use of "Merb" in the title. There's almost no Merb in
the content, and I only forced myself to use it because I personally needed to
learn it before it devours Rails.

  > Did Crispin and Gregory use this term?

If they did, would I be off the hook? That's "appeal to authority", you know...

  > When I saw your letter, I was
> thinking, how could you /possibly/ make a mind map out of a collection
> of tags?

Posts are the nodes, and tags-in-common are the edges. But...

  > When I saw the example I immediately thought, "oh! you mean
> concept graphs". Because to me, a concept graph is a collection of
> nodes, each containing a keyword, and linked by lines.
>
> A mind map is what Tony Buzan invented, and what MindJet implemented
> (and many others copied): a radially drawn tree with a central concept
> fleshed out in increasing detail, with pictures and annotations to
> illustrate and clarify the concept.

Point. I picked up "mind map" because it's a cool term I saw around the
interthing. There are two remaining issues:

   - if you blog about your favorite topics (such as "sex", "drugs",
      and "rock-n-roll"), then the links between your posts will
      indeed map your mind

   - I auditioned some GraphViz tools that display radial links out
      from a root, but I couldn't briefly get them to look right
      in a bloggable format

The "mind map" I learned in the 1970s might have gone under a different name. I
don't recall it - obviously. It's a classroom note taking technique looking like
this:

      +-----------------
     /              +----
    /          /---/____
   +---+------+--------
        \
         +---+-------
              \_______

It's a side-ways outline on paper, formatted to make adding new callouts easy.
Maybe GraphViz can do that, but it should not require excess directives. I
wanted to avoid fun like "noderank".

> Sorry to be pedantic, but I think it's a valuable distinction.

Distinct pedantry is where it's at!

--
    Phlip

I like the concept Phlip, and it's impressive you can achieve that much with so
little code.  It also looks like a very useful way of presenting a collection of
blog articles.  Very helpful for someone trying to figure out where to go
exploring an archive.  So when are you going to substitute this for your blog's
tag cloud?



Nevertheless, I must quarrel with your use of the term mind-map.  Did Crispin
and Gregory use this term?  When I saw your letter, I was thinking, how could
you /possibly/ make a mind map out of a collection of tags?  When I saw the
example I immediately thought, "oh! you mean concept graphs".  Because to me, a
concept graph is a collection of nodes, each containing a keyword, and linked by
lines.

A mind map is what Tony Buzan invented, and what MindJet implemented  (and many
others copied): a radially drawn tree with a central concept fleshed out in
increasing detail, with pictures and annotations to illustrate and clarify the
concept.

Sorry to be pedantic, but I think it's a valuable distinction.

Alan Baljeu




________________________________
From: Phlip <phlip2005@...>


Netizens:

Crispin & Gregory's new book, /Agile Testing: A Practical Guide for Testers and
Agile Teams/, has a kewt "mind map" at the start of each chapter. It inspired me
to find a way to use the "tag cloud" on a blog to draw a mind map of the posts,
linked by their tags in common.

The result is this little project:

http://broadcast. oreilly.com/ 2009/02/merb- mind-maps. html

It showcases...

- graph theory - including Minimum Spanning Tree
- GraphViz - to typeset the mind maps
- Merb - a Rails-style website platform
- Ruby - that annoying language that won't go away
- RSpec - a Behavior Driven Development system
- transparent PNG files with ImageMagick drop-shadows
- assert{ 2.0 } - an assertion that reflects its expressions
- assert{ xpath } - the latest version of my assert_xpath system
- TDD for algorithms & graph theory!
- fixture-dependencie s - a Rails fixture clone with more features
- GraphvizR - a lite Ruby gem that wraps GraphViz dot notation
- and even a tiny bit of HAML!

The algorithm itself depends on none of those things, so any blog could use the
algorithm to present the mind-maps that are already latent within it!

_


       __________________________________________________________________
Instant Messaging, free SMS, sharing photos and more... Try the new Yahoo!
Canada Messenger at http://ca.beta.messenger.yahoo.com/

[Non-text portions of this message have been removed]

Netizens:

Crispin & Gregory's new book, /Agile Testing: A Practical Guide for Testers and
Agile Teams/, has a kewt "mind map" at the start of each chapter. It inspired me
to find a way to use the "tag cloud" on a blog to draw a mind map of the posts,
linked by their tags in common.

The result is this little project:

    http://broadcast.oreilly.com/2009/02/merb-mind-maps.html

It showcases...

   - graph theory - including Minimum Spanning Tree
   - GraphViz - to typeset the mind maps
   - Merb - a Rails-style website platform
   - Ruby - that annoying language that won't go away
   - RSpec - a Behavior Driven Development system
   - transparent PNG files with ImageMagick drop-shadows
   - assert{ 2.0 } - an assertion that reflects its expressions
   - assert{ xpath } - the latest version of my assert_xpath system
   - TDD for algorithms & graph theory!
   - fixture-dependencies - a Rails fixture clone with more features
   - GraphvizR - a lite Ruby gem that wraps GraphViz dot notation
   - and even a tiny bit of HAML!

The algorithm itself depends on none of those things, so any blog could use the
algorithm to present the mind-maps that are already latent within it!

Mark Levison wrote:

>> - test the model in isolation from the controllers & view
>
> So you would Mock the controllers and the views in this case?

If you look up an MVC diagram, the Model only has inbound arrows. Or the
equivalent. To TDD the Model you simply ignore the controllers and views,
because MVC requires them to decouple.

>> - TDD new back-end features from the bottom up, not top-down
>
> Bottom up? How do you do that? Don't you normally Test Drive from the top
> down? Building only what you need along the way?

Anything the user can do to the Model thru the Views and Controllers, a unit
test can do the same way, bypassing them. Get a list, select an item, update it,
etc. So bottom-up should be just as good as top down.

Top-down is also part of TDD's algorithm generation concepts...

>> - abstract relationships, such as has-many, into accessors on records
>
> I'm even more confused. Hopefully the example will cover both.

In ActiveRecord:

class Order < ActiveRecord::Base
    has_many :line_items
end

That's enough to find a table in the database called 'orders', find another
table called 'line_items', find their field 'order_id', and use it to populate
an array of LineItem model objects. The SQL is all hidden inside this, stretched
out among the declarations and conventions.

>> - test from a pool of example models ("fixtures") that mix-and-match
>> business rules
>
> Are you saying use sufficient sample data to exercise the paths through the
> business rules.

TDD will give you that. Rails makes it easy by letting you declare these pools
of records in your versioned source, _not_ in your database instance.

--
    Phlip

Sai wrote:

> I have been thinking about the points which affect UI testability for
> sometime. When it comes to unit testing there are specific points like
> Dependency Injection, usage of Singletons as factors which affect it.
>
> Similarly it must be possible to get a set of points which we must be
> able to do or avoid to help UI testability. I need your help in
> collecting these points so that it will help us while we think about
> design for testability at UI level.
>
> Some points to get started
>
> 1) Building custom controls like grids or tables either from scratch
> or from available controls. Sometimes I have seen people drawing their
> own controls which makes testing extremely difficult

If you are using an off-the-shelf control, such as an edit field, you can TDD it
by building its form, running production code to push data into it, then
querying the data out with the control's accessor methods. I am only talking
about TDDing from inside the same language and platform as that form - not
external UI testing.

If you invent a custom grid, or if you override the hooks in a standard control
to write your own special effects, then you must TDD the new art and input
itself. You can do that by intercepting your graphical paint methods at a level
equivalent to Gdk or Cairo. Then tests can query the paint methods back and
determine they are correct. You TDD the inputs by putting trace statements
inside your input handlers that reflect input events, then click or type on the
control, and convert the trace output into sample inputs for your test case.

Once the control works, then you can trust its accessor methods, and the
business-level TDD can access your data the same as with a standard control.

> 2) Auto generation of UI code. Most of the time it leaves us with
> randomly generated locators

The best thing about auto generation is you are not TDDing your generator
itself. So if you can TDD the script that you send into the generator, then your
unit tests save a lot of labor and noise by not generating at all.

We do this all the time in Rails, with that ubiquitous and infamous IU
generator, XHTML. Test-side parsers, such as .has_xpath or .has_selector
(meaning a CSS selector), or assert_xpath, are really tests that...

   - render the generating script from production code
   - parse the script (and assert it parses correctly)
   - drill down into its contents to isolate one context
   - TDD that business logic deposited the correct data inside that context
   - not feed the script into the generator (your browser)

So any generator script you use, you gotta get (or write) a parser script for
it.

> 3) Not using normal locators like id, name which makes testing complex.

There are situations where that does not work.

However, almost all of our TDD in Rails Views depends on...

   - generate a unique id for each container
   - use assert_xpath{ with a block } to isolate that container
   - use assert_xpath inside that block to detect logical data

All these assertions intend to provide the clearest possible assertions at fault
time. Constraining those blocks like that lets their fault diagnostics reflect
only their inner context. When an assertion fails, it does not spew out an
entire page! I don't know why, but other XPath test assertions don't let you use
a block to constrain your context...

> 4) Using technologies which don't have testability in built like Javafx.

We must come to a point, as an industry, where we start rejecting technologies
that can't be tested.

Until then, any port in a storm. I test JavaScript the same as XHTML - by
parsing it into a lite database, and then querying the database to detect
logical data. If, for example, the JavaScript is an Ajax response containing
JavaScript to update a DOM object and push in new XHTML content, I parse down to
that string, evaluate it, and stick it into the current XHTML context. Then
subsequent assert_xpath calls can detect important fields in the content.

Nobody else in the industry does this, and I don't know why...

> 5) Highly asynchronous process.

If you suspect a process might need threads, try as hard as possible to avoid
them. Invent your process, via TDD, without asynchronicity. Build your algorithm
to use time slicing, and TDD both the individual time slices and their gestalt.
This forces your code to have the kind of good structure it will need if you
then must make it asynchronous.

Call your time slices from a dispatcher, such as your windows's Timer event. If
the process does not work like this, only then should you move the dispatching
into a thread.

> Please let me know about your thoughts and challenges you faced in UI
> testability.

I intend to blog up a complete dissertation on each of these things. Quite
frankly, the biggest challenge for me has been trying to help the industry make
TDD for GUIs as easy as it is for me and my teams.

--
    Phlip

Hello, Phlip.  On Sunday, December 28, 2008, at 7:21:49 PM, you
wrote:

> Brian Marick has a book out on RubyCocoa. He's test-infected, but I don't know
> about the book. Has anyone tried it yet?

I would (and will) buy anything Brian writes.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Learn from yesterday, live for today, hope for tomorrow.
The important thing is to not stop questioning. --Albert Einstein

Chris Hanson wrote:

>> Has anyone successfully developed with TDD under Xcode?
>
> Yes, there are actually quite a few people who do extensive TDD on Mac
> OS X using Cocoa and Xcode — it turns out that it's actually a great
> platform for doing so, thanks to its objects-all-the-way-down (for the
> most part) design.

Brian Marick has a book out on RubyCocoa. He's test-infected, but I don't know
about the book. Has anyone tried it yet?

--
    Phlip

if you commented out this line (and any other line that squawks)...

>     @expected.parts << body_part      # <=== ERROR HERE

and printed out the mail's parts before asserting them...

>     mail = Notifier.create_notification()

     p mail.parts

...what would you see?

We TDD e-mails all the time, but we don't write huge bulk assertions. Sometimes
to test_first_, we cheat a little, write the correct code, print out what it
does, and then write assertions which trap the important details.

To test-first, when you need to change a mail, you clone that test, change the
input, change the assertions to expect different output, fail the test, then
pass it in the code. This shows how cheating, especially in high-bandwidth
situations like GUIs, can lead to better TDD...

--
    Phlip

jfalek wrote:

> All projects use Ajax and
> JavaScript (based on the prototype framework).

To unit test Ajax, you must generally test that your business model has injected
the correct data into the correct entry points in your Ajax library. Don't unit
test the wire protocol itself, or the JavaScript behavior in a browser. Rely on
thru-the-GUI tests to keep that end stable.

To detect business values, I let the HTML layer generate its output, with its
embedded JavaScript. I parse the HTML, as XHTML, with XPath, and tweezer out the
<script> tags. Then I drop their contents into a JavaScript lexer that turns its
variables into a data model. Querying this model should return the correct data
values.

That kind of test intercepts the values at the last moment before the GUI layer
takes them over. And (under Ruby on Rails) the test start by mocking the server,
so we have no excess programs anywhere. No web server, internet wire, web
browser, DOM, or JavaScript come between our unit tests and the tested code.

--
    Phlip

James Carr wrote:
> Hi All,
>
> Our team has a lot of UI tests that run from fitnesse... these either
> use fixtures backed by httpUnit, HtmlUnit, or Selenium and test user
> requested functionality through the frontend (i.e. going through user
> paths and whatnot). Although this method has worked well (with a few
> small kinks), it's always a bit slow and I've always been a bit weary
> using fitnesse as a UI testing tool as it doesn't quite feel like it's
> the right tool for the job.
>
> My curiosity is how others have set up their UI testing frameworks of
> choice? Anything that works well?

How many tests do you have that treat UI objects as objects? I mean unit-level
tests that just assemble some GUI controls, activate the production code to
populate their properties, then query the properties back.

If you are not inventing a GUI from scratch, you shouldn't need to test the last
step - rendering the controls into a display.

--
    Phlip
    http://broadcast.oreilly.com/2008/10/testing-rails-partials.html

This month at Extreme Programming San Diego (XPSD), Dan and Llewellyn will
teach us how to write Approval Tests. The meeting will take place at
Cardinal Health at 6pm on Thursday, November 6th.

** Approval Based Tests **

Write your code, run it, see that it works. This is a familiar process to
all programmers. The addition of 1 line of code can now make that a
repeatable automated regression test!

Well tested code has been shown, over and over, to improve the quality and
maintainability of software. Yet most projects are not well tested. Why is
this? Too often programmers feel that testing imposes too high of an
overhead on writing code.

In this talk, our goal is to make it easier and faster for you to write unit
tests.

We will show how using approval tests, in addition to asserts, will great
increase not only the ease and speed of writing a test, but the completeness
and maintainability of those tests; bridging the gap between people who
don't write tests, and test driven developers.

"I feel like I have to write my code twice." Right now, unit tests impose a
difficult step upfront of knowing exactly what you want. Asserting this
outcome then becomes cumbersome the more robust & detailed it is. After
that, maintaining the test becomes equally cumbersome. Because of this,
tests either get written, or get discarded, leaving untested code which is
fragile, error prone and leads to the nightmare of maintenance so many
experience.

After this talk, you should find yourself spending less time writing tests,
yet having better tested code, a proven way to increase successfulness of
your software.

"After I heard Dan & Llewellyn talk about approval tests, I tried it out. in
the first 4 minutes I was testing my code" - C. Monkey

"I find myself writing more code just so I can write more approval tests!" -
Script Kiddie

"All my life I'd sought approval from other developers, now I can approve on
my own" - Noself E. Steam

"With all the time I saved, I actually learned to talk to women" - Anonymous


The meeting will be held at Cardinal Health San Diego Headquarters (
http://xpsd.org/CardinalHealthDirections ) from 6-7:30 PM on Thursday
November 6th.


http://xpsd.org
http://llewellynfalco.blogspot.com/2008/10/approval-tests.html

This month at Extreme Programming San Diego (XPSD), Dan and Llewellyn will
teach us how to write Approval Tests. The meeting will take place at
Cardinal Health at 6pm on Thursday, November 6th.

** Approval Based Tests **

Write your code, run it, see that it works. This is a familiar process to
all programmers. The addition of 1 line of code can now make that a
repeatable automated regression test!

Well tested code has been shown, over and over, to improve the quality and
maintainability of software. Yet most projects are not well tested. Why is
this? Too often programmers feel that testing imposes too high of an
overhead on writing code.

In this talk, our goal is to make it easier and faster for you to write unit
tests.

We will show how using approval tests, in addition to asserts, will great
increase not only the ease and speed of writing a test, but the completeness
and maintainability of those tests; bridging the gap between people who
don't write tests, and test driven developers.

"I feel like I have to write my code twice." Right now, unit tests impose a
difficult step upfront of knowing exactly what you want. Asserting this
outcome then becomes cumbersome the more robust & detailed it is. After
that, maintaining the test becomes equally cumbersome. Because of this,
tests either get written, or get discarded, leaving untested code which is
fragile, error prone and leads to the nightmare of maintenance so many
experience.

After this talk, you should find yourself spending less time writing tests,
yet having better tested code, a proven way to increase successfulness of
your software.

"After I heard Dan & Llewellyn talk about approval tests, I tried it out. in
the first 4 minutes I was testing my code" - C. Monkey

"I find myself writing more code just so I can write more approval tests!" -
Script Kiddie

"All my life I'd sought approval from other developers, now I can approve on
my own" - Noself E. Steam

"With all the time I saved, I actually learned to talk to women" - Anonymous


The meeting will be held at Cardinal Health San Diego Headquarters (
http://xpsd.org/CardinalHealthDirections ) from 6-7:30 PM on Thursday
November 6th.


http://xpsd.org
http://llewellynfalco.blogspot.com/2008/10/approval-tests.html