Primitives, Unit Tests

[ceg]

Reading through the Revolution documentation provided with Enterprise, I was hoping to discover the true commands which could be classed as "primitives" (main building blocks) and those which are "library based" functions.

Is it a simple matter of the difference between command and function?

Is there an easy way of determining the dependency of library functions on either other libraries or primitives?

---
Second question (can you tell that I came from a Java background!!!) - are there any libraries which can be used to invoke automated testing - i.e. send messages to buttons, and record results? If not, I see an opportunity.

Cheers...

[Mark]

Dear Ceg,

If a command or function handler depends on libraries, I usually write this in a comment added to the handler, if the dependency is not obvious.

I don't know about a way to do automatic testing, but I do know that this subject came up before, on the Rev Use Mail list.

Best,

Mark

[trevordevore]

In regards to unit testing -

I have a basic unit testing kit for my projects that I have been slowly putting together though I do not have much prior experience in this area.

If you have experience in this area and are interested in creating a proper testing kit for Rev I would be happy to send you what I have to look at. It may give you some ideas on how to (or maybe how not to ) approach a solution in Revolution. Having a proper testing kit available for Revolution would be a very good thing.

[ceg]

When I've looked at testing in the past, its always really been as a precursor to coding -i.e. defining what I want to get out of the system and how it should be behave across a typical user experience.

For example, I'd setup full user experience tests of the core behaviour that the application MUST exhibit. For an e-commerce site, this is probably LOGIN -> SEARCH FOR PRODUCT -> SELECT PRODUCT -> ADD PRODUCT TO BASKET -> CHANGE QUANTITY -> CHECKOUT. With tests for login, product visibility, product price, product in basket, quantity reflected, delivery, vat, and checkout confirmation.

For a test suite I'd expect to be able to produce:

(1) Scenarios (or steps)
(2) Step breakpoints (for debug)
(3) Population of fields or (for walk through)
(4) Invoking buttons/handlers
(5) Recording results

SQLite type database driven system with a number of tests, tests broken into generic steps, each generic step has object, card, action, data in, data out (result). Generic steps can be shared across tests.

Is this along similar lines?

[FourthWorld]

I usually put most of the core routines into libraries or backscripts, so among other things it's easy to call them from testing tools. For complex stuff I'll often make a simple test stack that covers the functionality of a library before making the UI for it, so the routines can be tested in isolation.

Like Mark S., I often put comments in noting where a particularly dependency may be, and even more frequently I use a prefix in my library handlers to denote where they are (stuff in stdLib.rev for example is mostly prefixed with "stdlib", e.g., "stdLibAlertLoc"; stuff in my DB library is prefixed with "fwdb", e.g., "fwdbGetRecord").

Another convention I use is for any handler without a special prefix I capitalize its first letter, leaving all built-in commands and functions with that first letter lower-case. I find this helps custom stuff stand out visually when skimming code.

When in doubt, I added a lookup feature to my script editor so I can select a token and type Cmd-"," and it finds the defining handler and opens that script. If I've selected a built-in token it opens the Dictionary to the appropriate entry. I believe Jerry's GLX2 now has this capability as well. It's very handy.

I've been tempted to write a tool that will generate a calling chain for any command or function, but I haven't yet had enough of a need to move it past the theory stage.

[trevordevore]

I believe Jerry's GLX2 now has this capability as well. It's very handy.

The ability to click on some code and and open the script where the handler resides (or the dictionary if it is a token) has been around since before GLX2. I think it was in GLX2 that Jerry truly integrated the nifty visuals (i.e. handlers appear as hyperlinked text). I find it very difficult to go back to reading scripts that are not formatted this way. Being able to glance at a handler and know all of it's external calls instantly is very handy while reading through the code.

[trevordevore]

For a test suite I'd expect to be able to produce:

(1) Scenarios (or steps)
(2) Step breakpoints (for debug)
(3) Population of fields or (for walk through)
(4) Invoking buttons/handlers
(5) Recording results

SQLite type database driven system with a number of tests, tests broken into generic steps, each generic step has object, card, action, data in, data out (result). Generic steps can be shared across tests.

Is this along similar lines?

Currently I have tests segmented into Libraries and UI. I have the library tests working but i haven't done anything with the UI tests yet. Like Richard I put the majority of functionality in libraries so that was the most important part for me to get working first.

Currently there is a test stack that contains your tests and a suite of handlers that can be called during tests. Each card contains related tests and there is a button on the card for each test you want to run. Each card also has a related folder on disk that can contain resource files for testing (database file for testing, PDF file to compare output from a library against, etc.)

If you had 2 buttons (tests) on a card then this is how the test would be run for each button:

1) SetupTestData message sent to card (shared setup for all tests on card)
2) Setup message sent to button
3) Run message sent to button
4) Cleanup message sent to button
5) CleanupTestData message sent to card

During the test you can make calls to handlers like 'verify' and 'verify_equal' which log success/failure to a log. Results are then displayed when all tests have completed. I have little helper handlers in there for comparing arrays, properties of controls, etc.

The UI portion of the testing suite should do some of the things you mention in your list above such as populating fields or clicking on buttons. Ideally this would be run from a standalone version of your application however so that you don't actually do anything harmful to your application while working with the tests.