Unit testing in Rev

Stop by to discuss use cases, requirements, information architecture, flow diagraming, unit testing and usability.

Moderators: FourthWorld, Klaus

Post Reply

Test Driven Development in Rev

Why do we need unit test? I click here and it just works.
3
21%
There's not really great ways to unit test in Rev because, you know if it's good if it works.
0
No votes
I use TDD in Rev and it rocks.
1
7%
I'm interested in learning more about TDD in Rev
10
71%
 
Total votes: 14

docwes
Posts: 10
Joined: Mon Jan 19, 2009 8:15 pm
Location: USA
Contact:

Unit testing in Rev

Post by docwes » Mon Jan 26, 2009 7:27 pm

So a little background on me I am a Web Developer by day Flex/Flash also Python, javascript and coldfusion. And at home I work with c++/blitzplus for my gaming stuff and now most recently a "revolutionista" as Jerry puts it :p

At work we are really into TDD Test Driven Development and writing good testable code.

Now so far with Rev as things are done alot differently than typical programming languages and workflow, I'm very interested if anyone is doing test driven development in rev? As well as how you write your test.

I will be researching this as well as coming up with ways to write my own test but it would be great to get some insight from the advanced/Geniuses among you. Lets Talk TDD!!

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Unit testing in Rev

Post by FourthWorld » Mon Jan 26, 2009 8:44 pm

Really great topic, Doc (of should I call you Wes?).

Hopefully Mark Wieder and some of the other testing gurus around here will chime in.

I think you hit the nail on the head here:
docwes wrote:Now so far with Rev as things are done alot differently than typical programming languages and workflow...
Ain't that the truth! :)

I find Rev uncommonly productive, but via means that are equally uncommon. Accordingly, many of the practices common with other languages are almost as rare with Rev work as compile cycles.

For myself, I tend to build testing tools for complex subsystems within an app, to make sure those subsystems are airtight and have a useful API before I try to roll them into a larger project.

The older I get the more I tend to put code into reusable libraries, taking a little extra time to generalize them to save that much more time on everything else I make with them down the road. For each library I usually build a test UI to not only make sure I'm getting the results I expect, but also to benchmark performance, trying out different ways of doing things to optimize them, looking for that optimal balance between development convenience and runtime responsiveness.

But in general that's about as far as I go with TDD, focusing on the reusable parts. For the minority of code in my apps that is specific to the app, I tend to do most testing in vivo since it's usually relatively trivial to make code and UI changes on the fly (ah the joy of never having to wait for a compiler <g>).

I would be interested to hear more about your own TDD practices, and also about your impressions of Flex and how it compares to Rev (the good, the bad, and the ugly). Always interested in learning more about other worthy tools, and Flex is especially interesting as Adobe's significant investment in it helps validate a lot idea about the development opportunities I outlined here some years ago:
http://www.fourthworld.com/embassy/arti ... tapps.html
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

docwes
Posts: 10
Joined: Mon Jan 19, 2009 8:15 pm
Location: USA
Contact:

:)

Post by docwes » Mon Jan 26, 2009 10:33 pm

Well Doc or Wes is fine. Doc came from my days as a marine corp corpsman.

Yeah im really interested on just coming up with ways to test.I like the idea of having a simple ui to test some of your components out. One of the things i think of the most when using rev is how to make my coding smarter and not code transcript but code into the language and utilize the best practices in dealing with the event pipeline and the messaging system.

So I know what my code should be doing before i code it and to make it testable means i really have a firm grip on what exactly i'm having it do.

Now the hard part with rev is that okay i got this button, I want when i click it that a screen pops up saying hello friend. Okay so i put that code in the button and it works when i click it tada.
If i was going to write a test, it should probably consist of me testing that the button click triggered and answered my string right.

To me this is more pertinent to test if the button triggered function resides in the stack, where say all the rest of my code is, then maybe i can write a test that randomly passes in different strings to this one button and that it pops up the screen with the appropriate string in it every time.

Is that overkill for an example? probably but what if it wasn't a button, what if it was a database table or a value object?

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9801
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Post by FourthWorld » Mon Jan 26, 2009 11:01 pm

Semper fi. Thank you for your service.

As far as what's overkill and not, hard for me to say in general terms. Clearly a button that simply puts up a dialog is simple enough to test on its own, but your extension of that with a database table or a value object may lend themselves well to crafting an isolated test stack.

Hopefully Mark Wieder will chime in here. He's one of the Rev community's more experienced testing gurus, though he's modest enough that he'll probably lambaste me for saying so. :)

In the meantime, maybe these two articles will be somewhat helpful as you craft your code:


Scripting Style Guide:
Helpful tips for xTalk, Lingo, and other 4GLs
http://www.fourthworld.com/embassy/arti ... style.html

Extending the Runtime Revolution Message Path:
An introduction to using Libraries, FrontScripts, and BackScripts
in Runtime Revolution's Transcript Programming Language
http://www.fourthworld.com/embassy/arti ... _path.html
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Post by mwieder » Tue Jan 27, 2009 7:35 pm

Always happy to join the party.

Let me split this into talking about unit tests and TDD separately, although there are obvious linkages.

I write unit tests for my library routines. I've got a unit test library that has functions like assert.IsEqual(x,y) and assert.IsNumber(n), and a set of handlers for setting up and tearing down tests to do any initialization necessary. The tests themselves are xtalk scripts which are executed using the "do" command in a try/catch construct with the results returned and logged. I store the tests in a sqlite database and have a GUI front end to make test suites out of individual tests for regression testing when I make new versions of apps.

This works well for library handlers. For UI testing the tests have to be more hand-crafted - I don't have a generic concept for "send mouseUp to button x, wait until response abc appears in field y or until timeout". And I don't have a way to test modal dialogs at all.

I'm big on TDD in general. The idea is that you write your tests, then write the code and tweak it until it passes the tests. I find this really useful in other development environments, but not so much for rev coding, and for a couple of related reasons. I tend to code bottom-up in rev rather than top-down. Part of this is the object-oriented approach of trying to compartmentalize as much as possible into individual objects and then connecting the objects when they need to communicate with each other. Writing tests for the intraobject messaging is useful, and I do that.

But the other problem with TDD in rev is that by the time I've conceptualized the pseudocode enough to write a test, I've essentially written the code. Xtalk syntax is close enough to the pseudocode that if I have to jot down the pseudocode in order to write a test for it, I've already written the code. I can still write the test, but it's not quite TDD.

There are exceptions to this. If I'm working with a database or I'm writing a specific library function there are expectations of the results, and so I'll write a test procedure that calls my function and throws an error if the result isn't exactly what I expected. More bottom-up programming.

Anyway, YMMV and I'm interested to hear what experiences others may have in this area.

docwes
Posts: 10
Joined: Mon Jan 19, 2009 8:15 pm
Location: USA
Contact:

Post by docwes » Tue Jan 27, 2009 10:12 pm

mwielder that is exactly what i was wondering u hit it right on the nail.
But the other problem with TDD in rev is that by the time I've conceptualized the pseudocode enough to write a test, I've essentially written the code. Xtalk syntax is close enough to the pseudocode that if I have to jot down the pseudocode in order to write a test for it, I've already written the code. I can still write the test, but it's not quite TDD.
But im very interested in what you where talking about with your library testing i am going to be building up a small library of components and i would like to have a way of testing them before they become a legal citizen in my library.
If you would be willing to share some of your library or at least how you came up with test for it i'd be more than willing to take that and once i get a handle on it put up a nice tutorial or screencast showing how to do it.
I do TDD in Flex, coldfusion and python all the time i really think TDD is great and would love to extend it to my rev addiction now lol. Thanks for the replies this is great stuff.

-Doc-

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Post by mwieder » Tue Jan 27, 2009 10:50 pm

Happy to share, but I can't figure out how to share stacks here, so pm sent.

Post Reply

Return to “Software Engineering”