Wow. I think this is a really interesting discussion, but it is completely
beside the point. It's like the really interesting and completely beside
the point discussion about threads. As i understand it, Shoes is for
walking and whistling at the same time. Shoes is for coding simple,
sometimes elegant, sometimes ugly but always cool apps. Remember what
really cool trash we created with BASIC? Remember how 7 year olds in their
pajamas could write actual programs that did cool things? We didn't do unit
testing. The edge case was that some kid might spill his orange juice on
the keyboard because he's jumping up and down and laughing out loud because
his program is drawing the most beautiful fractal.
Sure, Basic grew up, grew functions and subs, and abandoned its shameful
gotos of the past. I had a book, QuickBasic for Scientists. Basic had a
low entry threshold that meant you didn't have to be a professional
programmer or computer scientist to get into it and to do good work with
it. Basic allowed us artists and scientists and teachers and cooks and
white collars and blue collars to harness the awesome power of the personal
computer, and bend it to our will. I remember being thrilled to make a pc
work all night on problems i gave it. There it was, crunching mindlessly,
doing millions and millions of repetitive calculations so that i wouldn't
have to.
So, i think this idea of the low barriers to entry is integral to _why's
vision for Shoes and HacketyHack, but he can correct me here. His Camping
seems to have been created in a similar spirit, in reaction to the
comparatively heavy and complicated Rails. MVC, sure, but put it all in one
file, one smallish file.
I don't mean to stifle the discussion. You can ignore me at any rate. I
just hope you find fulfilling ways to contribute and that you don't get
discouraged if Shoes ambles along its own surprising and delightful path.
peace,
dan
On Mon, Apr 14, 2008 at 8:27 AM, Phlip <[EMAIL PROTECTED]> wrote:
> Luke Bayes wrote:
>
> Even being the best, I'm pretty sure we can all agree that it's not quite
> > a simple as you've stated above. How deep should those tests go?
> >
>
> You test behavior. The majority of HTML is structural, and submits to
> visual inspection.
>
> How fragile are they?
> >
>
> You run the tests as often as possible, while changing the code. This
> shakes out the fragility. A test that fails too often you make "fuzzier".
> For example, this assertion detects an input field inside a form:
>
> assert_xpath '//form/[EMAIL PROTECTED] = "foo"]'
>
> If someone rearranges the graphics inside the form, you must reduce the
> restriction that the input is an immediate child of the form:
>
> assert_xpath '//form/descendant::[EMAIL PROTECTED] = "foo"]'
>
> assert_xpath provides : as a shortcut for that:
>
> assert_xpath :form do
> assert_xpath :'[EMAIL PROTECTED] = "foo"]'
> # more assertions here
> end
>
> > Which HTML snippets should be verified?
>
> Roughly speaking, the ones which contain <%= %> should all be
> test-firsted, to ensure the business logic provides the correct outputs into
> the tests.
>
> > Which should not?
>
> Things which are easy to spot and fix if they are wrong.
>
> > How do we teach others to write those tests?
>
> Pair programming. A newb at my day job recently called out our colleague,
> who'd been there for a year, for not TDDing enough. I'm so proud...
>
> > What does this mean in an AJAX world?
>
> The exact same thing. Where assert_xpath uses Hpricot, REXML, or Libxml to
> extract the payload from HTML strings, assert_javascript uses
> Javascript-PurePerl to convert Javascript into XML describing its parse
> tree. Then assert_xpath can attack that.
>
> assert_xpath './/input[ @type = "image" ]' do |input|
> assert_javascript input.onclick
> assert_xpath './/Statement[2]' do
> assert_js_remote_function '/user/inventory/' do
> json = assert_js_argument(2)
> params = assert_params('uri?' + json[:parameters]).last
> assert_equal @user.id.to_s, params[:user_id]
> assert_equal @user.inventory.first.id.to_s, params[:inventory_id]
> end
> end
> end
>
> That tests the onclick has an Ajax.Updater that calls the inventory action
> with the user ID and the first inventory item ID. Those IDs are the payload,
> so the test must parse its way to them and isolate them. Anything else can
> change.
>
> http://assertxpath.rubyforge.org/classes/AssertJavaScript.html
>
> > Even though we aren't responsible for browser
>
> > bugs, it is our job to work around them, shouldn't our tests verify this
> > work too?
> >
>
> You can't use tests to prove the absence of bugs. The nightmare of browser
> compatibility illustrates this just as absolutely as tiny quantum-mechanical
> glitches in CPUs would.
>
> Yet tests ensure that once you identify a bug you can safely fix it -
> test-first - without too much concern the fix will break something!
>
> My understanding, which certainly could be flawed as I don't have any
> > real experience with it, is that RSpec basically gives us 'permission' to
> > write tests at a less granular level. By essentially creating that DSL and
> > naming it a 'specification', we can write tests against object interactions
> > in addition to isolated object behavior. This has the obvious side effect of
> > compromising defect localization, but it seems like that may be a useful
> > tradeoff in the context of GUI testing.
> >
>
> I don't understand why anyone would think that. We are not talking about
> "unit tests", which are a QA concept. A pure unit test must test objects in
> isolation, so if they fail you only must inspect one unit to find the
> problem.
>
> We are discussing "developer tests". If you run them after every edit,
> then if they fail you only need to revert the last edit to fix them. So if
> you only write code if you can get a test to fail, and if a given edit
> connects two (or 15) objects, then a test must cover that interaction.
>
> So why the hell does RSpec keep getting the good press here??
>
> --
> Phlip
>
