Important: about the Testing forum
This forum is for experienced users who would like to help test current and future versions of Textpattern. It’s not for discussing
general problems encountered “in the wild” with live Textpattern sites – that’s what the Troubleshooting forum is for.
Suggested topics include:
- Test reports (likely bugs encountered during testing) and confirmations
- Useful data for testing (example articles, templates, forms, database snapshots and so on)
- Discussing testing methods, resources, and problems
- Discussing new Textpattern revisions, from a “how do we test this?” point of view
For now, we’re concerned only with Textpattern’s 4.0.x branch. Crockery (4.1) is still experimental and includes many things that are likely to change.
If you’d like to help test Textpattern, here’s a quick how-to:
1. Use Subversion to fetch the current 4.0.x development version from http://svn.textpattern.com/development/4.0/.
2. Install this fresh copy in a “sandbox” – a separate subdomain or subdirectory, or on your local machine, with it’s own database. To avoid accidents, we strongly recommend against sharing a database with a live Textpattern site.
3. (Optional but recommended) Immediately after installation, capture a snapshot of the database. This will make it very easy to restore your test sandbox to its original state without having to re-install Textpattern. You can do this with phpMyAdmin using the “Export” function, or with the following command line:
mysqldump -c -u mydbusername -p mydbname > snapshot.sql
To restore the snapshot at any point, use phpMyAdmin’s ‘SQL’ tab and upload your snapshot file, or the following command line:
mysql -u mydbusername -p mydbname < snapshot.sql
4. Test. Look for problems and think up tricky situations. Watch the timeline for new features and bug fixes, and test those. Make sure new changes don’t break old features.
By sharing ideas on the Testing forum, we can gradually build a collection of standard test data: article bodies, snippets of template and form code, and snapshots of the correct output produced by those things.
You can help the bug fixing effort by testing unconfirmed reports from the Bug Reports forum. Often these bug reports don’t include all the
necessary information. If you can find a way to reproduce the bug in your default sandbox, you’ve confirmed the bug.
5. Post any problems you find on the Testing forum so that others can help confirm it. Ideally, we need to know the steps required to
reproduce the problem on a default installation; the actual output (i.e. the buggy results); and the expected output (what should happen, if the bug wasn’t there).
We’ll move confirmed reports to the Bug Reports forum as required. (In some cases, that might not be necessary: a clear, confirmed test report makes it very easy to fix bugs)
6. Keep up to date with new revisions, and keep testing.
If you happen to know PHP, feel free to try your hand at debugging the problems posted on the Testing forum.
Re: Important: about the Testing forum
Note: I use latest revision on several (small to small-medium size) production sites (i update once in a week to everyday, depending on when I saw something nice on the timeline), always have been since Zem joined the dev team. And no problem (with two old exceptions).
HEAD revision on 4.0 branch (strangely labeled “development”) is very stable. I do not recommend you (as in you, reader and TXP user) do the same, you could loose datas or have downtime, but still it’s quite impressive.
Last edited by Jeremie (2006-03-01 08:44:45)
Re: Important: about the Testing forum
NB, we could also use positive reports (i.e. “works for me”), particularly for larger changes, or anything that might work differently on different servers. As well as making sure that new things work and bugs are fixed, we need to make sure that we haven’t broken something else in the process.