simpletest

Hello everyone!

I'm having problems when trying to add tags to the story/page creation form using simpletest.

I have a vocabulary which uses FREE TAGGING, and I want create a new page with the tag "cat". The vid of the vocabulary is stored in the class attribute 'free_tagging_voc'. What I've been trying to do is the following:

So in the process of writing my first test I found a bunch of documentation discrepancies at http://drupal.org/simpletest

I'm not yet familiar enough with everything to know exactly what's deprecated, what's best practices/optional etc. so starting this to bring them up - then we can just edit stuff directly on the page once it's confirmed it needs changing. Or if they're not salvageable, just archive them quick so we're not presenting misleading information and replace with http://groups.drupal.org/node/11020 when it's ready.

Hello, I've written a perl script (fastens fire-proof suit) that generates module files as well as a test file complete with a test class and stubbed methods. I've posted the code as an issue to the simpletest module as webchick suggested: http://drupal.org/node/233261

From the documentation:

Features:
- creates a module folder and associated file skeletons
- generates a test class and test methods and places them in a test file
recognized by SimpleTest. This currently only covers unit tests,
and not higher level tests like functional or integration tests.

Background and Purpose
After the SimpleTest session Wednesday morning I talked with sethcohn about some possible solutions to some of the issues that are being faced with full scale implementation of the unit test coverage. Some of the ideas are specific to the SimpleTest framework, but much could be applied to other testing frameworks. According to chx it sounds like the SimpleTest framework is going to be used which makes this information especially relevent.

To start off the biggest unknown currently is how to go about implementing "function unit testing" (which I beleive is the term). In other words calling an individual function with different arguements and checking the results against the know correct output. Until now this has been virtually untested and, to my knowledge, not really thought about at all. Instead "functional" testing has been worked on (as I was apart of).

We received, by show of hands, a considerable number of people who claim to be interested in contributing to the testing challenge, as introduced by Dries in his keynote. If anywhere near the number of people that raised their hands contribute, it could create a very chaotic situation and put a lot of pressure on the SimpleTest maintainer(s). In an attempt to address this I have compiled some ideas and thoughts.

A question which a bunch of people asked at Drupalcon (including me) was how to know which modules and functions have tests (and which don't). This is useful both for computing test coverage and for knowing where to focus efforts as we try to build initial coverage for core.

There are tools which do % of test coverage, but according to the BOF today, they tell you line numbers rather than functions - a useful metric but not perfect.

In Dries' keynote on Monday, he announced that he was willing to push back the code freeze to mid-October if Drupal has full test coverage. This is going to require a cultural shift towards test-driven development that is supported by a community who writes both functional and unit tests. This will ensure that improvements in one area of Drupal don't cascade and break other areas, which means that more time is spent in the development cycle fixing bugs rather than adding new features.

The unit testing working group met with Dries on Tuesday morning, and they came up with a tentatively-approved plan to start including SimpleTests in core. This will emphasize the importance of writing testable code, but requires active support from the Drupal community to help write functional and unit tests.

If there isn't enough progress by May, then Dries will be forced to shorten the code freeze and focus on fixing bugs. On Monday morning, four members of the testing working group presented the following information on the SimpleTest framework and the future of test-driven development in Drupal.

So I am writing a new CCK field and because I practice test driven development I find myself testing that I have implemented the CCK api hooks correctly. This basically means testing against the interface. Usually in a pure OO class orientated world for unit testing we would use a mock library (e.g.

This is the best bit from my blog post: http://starbowconsulting.com/blog/tao/simpletest-tips
(Also, if anyone want to read me rant about the state of unit testing in drupal: http://starbowconsulting.com/blog/tao/joys-unit-testing)
Validating HTML Fragments
I am currently working on code that generates html fragments. Simple Test out-of-the-box does a great job helping you test entire http pages, but only it if goes and gets them itself. I could not find any easy way to load in a local page/fragment. So I did it the hard way:

I am trying to functional testing on a custom node creation form, and cannot figure out the correct syntax for selecting the taxonomy terms.

One of the biggest concerns about automatic testing is how to prevent potentially dangerous code to cause harm to the server and other tests.