gmane.comp.programming.test-first-user-interfaces

[TFUI] Re: Integration Test Servers for Videogames

Phlip — 2012-07-09T18:48:39

On Mon, Jul 9, 2012 at 9:25 AM, Michail Ostrowski
<michail.ostrowski-8qTHflVfW6aELgA04lAiVw< at >public.gmane.org> wrote:

Awesome. I honestly hope that game programmers will look at tools like
this more.

However, I'm doing 2D in-house websites for big companies now (instead
of fragile fly-by-nighters like High Moon), so I'm really out of the
loop for both the game industry and 3D unit tests.

[TFUI] Re: [TIP] running away from RSpec

Phlip — 2011-02-12T22:26:52


Because, frankly, it sucks. See below...


We tried RSpec at Integralnet, for several months, and it's a ton of
syntactic sugar around one tiny granule of salt.

In pseudo-code:

  setUp
      x = 42

      specs using x

      setUp
         y = 43

         specs using x and y

That's all there is to it - "subcontexts". The incredibly trivial feat
of nesting two setUp definitions so a test can use fixtures from both.

The rest is nothing but everted assertion syntax, and 'clever strings'
in place of stodgy_method_names. Oh, and every fixture and reusable
assertion you write for TestCase, you gotta write it again for RSpec,
because it uses a completely different framework.

You /could/ do all that in Python, even without too much self. clutter. But...

RSpec is incredibly over-represented in the Ruby space for a simple
reason - it presents the empty promise of Behavior Driven Development.

The _point_ of BDD is your civilian clients (your Onsite Customer) can
author test scenarios without worrying about _

RE: [TFUI] TFUI is about objects, not screens, and Rails is the best TFUI for the web

석한울 — 2010-12-29T16:33:33

Thanks Phlip I tried find your book to buy.. but i couln't
your book has sold out.
that made me Sad..

but now I feel greate!! thank you very much

and thank you about that you share valuable informations and your knowledge
-----Original Message-----
From: "Phlip"&lt;phlip2005-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org&gt; 
To: testfirstuserinterfaces-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org
Cc: 
Sent: 10-12-29(수) 02:12:49
Subject: [TFUI] TFUI is about objects, not screens, and Rails is the best TFUI for the web

hanuri7421 wrote:
All desktop views are different, and all desktop views are the same.
They always allow you to declare a window and its controls in code, as
objects. So for each method that configures your view or pushes data
into these objects, there's another method that queries that same data
out of the objects. (Warning: Sometimes these methods are not fully
documented!)
My book on TFUI shows how to do this for WTL. Each step should
trivially map onto any other View platform:
http://www.zeropl

[TFUI] TFUI is about objects, not screens, and Rails is the best TFUI for the web

Phlip — 2010-12-28T17:12:49


All desktop views are different, and all desktop views are the same.
They always allow you to declare a window and its controls in code, as
objects. So for each method that configures your view or pushes data
into these objects, there's another method that queries that same data
out of the objects. (Warning: Sometimes these methods are not fully
documented!)

My book on TFUI shows how to do this for WTL. Each step should
trivially map onto any other View platform:

http://www.zeroplayer.com/tfui/TestFirstUserInterfaces.doc

Disclaimer: TFUI is not about screen scraping, or capture playback, or
all the other heavy tools that apply "outside" the application. TFUI
is about testing views as an extension of your TDD (and BDD) test
cases.

joobn wrote:


Do your programmers use TDD?

sangpire


Ruby on Rails has the best TDD for websites (and it's fully
TFUI-compliant!) That platform is (therefor!) so popular that you will
probably find a book on it in your language.

(You could tell us what your language is, to

RE: [TFUI] pytest is better than assert{ 2.0 } (except it's in Python! Bleah!)

Tanksley, William D. Jr. — 2010-11-30T16:07:16

Yes, and note that Python is finally getting rid of its "print" magic too.

BASIC's PRINT statement is far from its only problem -- essentially the whole language is a patchwork of special forms.

...and I'm not sure about the whole "is more important than" thing. I'm not big on prescriptiveness in computer languages. Yes, reflection is a good thing; but it's not the _only_ thing. There is no perfect language, because the universal law holds: "All software sucks." Tradeoffs everywhere.

-Wm Tanksley

Re: [TFUI] pytest is better than assert{ 2.0 } (except it's in Python! Bleah!)

John Roth — 2010-11-28T07:14:14

Go is C warmed over. It's even being implemented by
some of the same team that worked on C and Unix,
specifically Ken Thompson.

It's a much better language, but then you'd expect
that after 40 years.

I'm not sure how you'd build an intelligent assert in
it, but then I'm not all that familiar with Go. It doesn't
use the standard try/catch (or whatever it's called in
your favorite language). It's got something completely
different.

John Roth





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

Re: [TFUI] pytest is better than assert{ 2.0 } (except it's in Python! Bleah!)

Phlip — 2010-11-28T05:35:40

Noted but I suspect the ability to build a reflecting assert, at the
language level, is more important than simply providing one.

The cautionary tale here is BASIC's magic PRINT statement. It does
things nothing else in the language can do, because it's implemented
at the parser level. Don't do that!

RE: [TFUI] pytest is better than assert{ 2.0 } (except it's in Python! Bleah!)

Tanksley, William D. Jr. — 2010-11-28T05:31:18

I don't think Go has any of the features I mentioned; in fact, of the
features I've seen, only garbage collection is common to the two
languages. In particular, Go doesn't have a prettyprinting assert
statement, which is important in the context of this conversation :-).


-Wm Tanksley

Re: [TFUI] pytest is better than assert{ 2.0 } (except it's in Python! Bleah!)

Phlip — 2010-11-28T05:25:26

It's Go time!

( Specifically, Google's Go language sounds exactly like that... No
idea if it actually is ;)

--
  Phlip
  http://c2.com/cgi/wiki?ZeekLand

RE: [TFUI] pytest is better than assert{ 2.0 } (except it's in Python! Bleah!)

Tanksley, William D. Jr. — 2010-11-28T05:11:58

Hey, Phlip. It's been a while.

I just saw the Cobra language http://cobra-language.com/, which is sort of a cross between Python, Ruby, Eiffel, Objective-C, and C#. Dot-net platform, but Mono is explicitly supported, so it works cross-platform.

Its assert statement (and its invariant statements, and its test statements) print out that sort of information.

Interesting language -- it has syntactic support for unit tests. Not the first I've seen, but definitely it's the cleanest I've seen. It also has blocks (like Smalltalk and Ruby), but without the need for curly braces (it uses Python-like block syntax). An interesting experiment.

-Wm Tanksley

[TFUI] pytest is better than assert{ 2.0 } (except it's in Python! Bleah!)

Phlip — 2010-11-27T02:55:29

TDDers:

A while ago I invented an assertion, assert{ 2.0 }, that reflects its
expression and all intermediate values when it fails:

 x = 7; y = 10; assert { x == 7 && y == 11 }
    ==>
   Expected ((x == 7) and (y == 11)), but
       (x == 7) is true
       x is 7
       (y == 11) is false
       y is 10

Actually, that's not my assertion, it's Wrong.rb, by Alex Chaffee. His
diagnostic itself is slightly different, but note that it reflects the
variable names and values. That's the point of assert_equal() and its
ilk. You _can't_ say == in your assertion, despite the readability
benefits, because assertions must compete with debugging.

An assertion, when it fails, should work like debugging with a "local
variables watch" feature.

http://github.com/alexch/wrong

Today I successfully auditioned pytest, and it has a better version of
this technique. It leverages Python, which has different reflection
systems. Its faults look like this:

    def test_function():

E       assert 3 == 4
E        +  where 3 = f

[TFUI]

2010-06-19T06:17:01

http://ftvt.allew.com

Re: [TFUI] My book on TDD for Views is available online

George Dinwiddie — 2010-04-08T17:56:46

And here I thought you were just testing to see if people read it or 
not. ;-)

Phlip wrote:

Re: [TFUI] My book on TDD for Views is available online

Phlip — 2010-04-08T16:17:40

oy nobody likes SVG->PS! I will run it thru an alternate translator &
repost. (Oh, and _check_ it on those platforms!)

Also I could bust them down to rasters; they were, of course, ready to
be used as mechanicals!



--
 Phlip
 http://c2.com/cgi/wiki?ZeekLand

AW: [TFUI] My book on TDD for Views is available online

Lundak, Jiri — 2010-04-08T15:21:47

Hi,

Same here with OpenSuse Linux.

Cheers.
Jiri

-----Ursprüngliche Nachricht-----
Von: TestFirstUserInterfaces-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org im Auftrag von Chet Hendrickson
Gesendet: Do 08/04/2010 17:04
An: TestFirstUserInterfaces-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org
Betreff: Re: [TFUI] My book on TDD for Views is available online
 
Hello,

I get the same on my windows machine.

chet

Thursday, April 8, 2010, 8:57:47 AM, you wrote:

Re: [TFUI] My book on TDD for Views is available online

Chet Hendrickson — 2010-04-08T15:04:56

Hello,

I get the same on my windows machine.

chet

Thursday, April 8, 2010, 8:57:47 AM, you wrote:

Re: [TFUI] My book on TDD for Views is available online

George Dinwiddie — 2010-04-08T12:57:47

Phlip,

Just so you know, the diagrams come out as black rectangles (sometimes 
with labeled white rectangles on them) when viewed with Preview on my 
Mac.  I haven't tried reading on a different machine, yet.

  - George

Phlip wrote:

[TFUI] My book on TDD for Views is available online

Phlip — 2010-04-03T16:09:38

http://zeroplayer.com/tfui/TestFirstUserInterfaces.pdf

It addresses these industry abuses:

 - skipping the View layer in TDD
 - testing the View thru a user-emulator (such as Watir!)
 - writing the View code first, then testing it (a little!)

The goal is new test cases drive new View features, without looking at or 
driving the View too often.

That is a tall hill to scale, hence the book is very dense. However, each 
chapter and case study contains its own Best Practices that can be learned 
alone, just by reading them.

Work with the book inspired my subsequent research with RoR, including 
assert{ 2.0 }, assert_xhtml{}, and assert_rjs_. An alternate Web chapter is 
my O'Reilly paper on TDD for Ajax: http://oreilly.com/catalog/9780596510657

[TFUI] doesn't... even... have... assert... match

Phlip — 2009-11-06T12:49:08

[sorry about the premature submit!]

TFUI:

Testing views is not always about testing thru-the-view, like capture-playback 
tests, or Watir or Selenium tests, that drive user interfaces.

It's about writing unit tests directly into the layer that runs the view. To get
there, you must treat controls as objects, and learn to bypass your
GUI's event loop.

One of the leading examples of TFUI is Ruby on Rails, and its exemplary support
for unit tests HTML views. When a unit test collects the HTML that would have 
traveled out the web server, it can parse it to spot the programmatic details. 
In RoR, anything you write into an HTML template with <%= %>, you should 
generally specify with a test. This "MockTheServer" pattern bypasses the web 
server's and browser's event loops.

This pattern allows your tests to lead development. You can write them first, to 
force your view to upgrade. That achieves TFUI.

So now we come to Django, another fine web platform that both learns from and 
teaches RoR a thing or two ab

[TFUI] doesn't... even... have... assert... match

Phlip — 2009-11-06T12:35:28

TFUI:

Testing views is not about testing thru-the-view, like a capture-playback test, 
or a Watir or Selenium test that drives a user interface.

It's about writing unit tests directly into the layer that runs the view. To get 
there, you must treat controls as objects, and generally learn to bypass your 
GUI's event loop.

One of the leading examples of TFUI is Ruby on Rails, and its exemplary support 
for unit testing HTML views. When a unit test

Do any Djangoists in the house have any confessions to make here? any exp

[TFUI] Re: why is Presenter First better for TDD?

Phlip — 2009-08-07T21:35:09


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


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


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.


Use Cases should not attach to user interfaces. The early User Stories are like
Use Cases, because the