Eskild Hustvedt

SWEC future plans

I’ve got some plans for SWEC in the future. One of its primary limitations at the time is that it can’t really do advanced tests using things like POST or specific pattern matching. So I’m planning a simple command-based file format where you can define advanced checks for sites, to compliment the already existing fully-automated checks.

The basic syntax will be something like this (any input is welcome):

URL http://...
GET
MATCH /regex/ or STRING
RUN_CHECKS

URL http://
POST 'SOME_POSTDATA'
MATCH /regex/ or STRING
[My regex] MATCH /regex/
[String equality] MATCH STRING
RUN_CHECKS

RUN_MAIN

Here any URL statement defines a new check, where all previous data is dropped. Each section can have a POST or GET statement, and then any number of MATCH statements, as well as a RUN_CHECKS statement. If any MATCH statement fails (ie. the regex doesn’t match, or the result isn’t equal to STRING) then it will skip the remaining tests and skip ahead to the next URL or RUN_MAIN statement.

MATCH is obvious, it runs a test on the entire content to see if it matches a regex, or equals a string. RUN_CHECKS would start the standard (SDF-based) SWEC checks on the returned data. RUN_MAIN would start the main SWEC mode [SOMETHING] MATCH would create a named match, so the content within [ ] would be the returned error if it doesn’t match, instead of something generic like “failed to match /regex/“.

Other commands I’ve thought of that I might or might not want to do include one to clean the cookiejar, so that tests can be performed on how a page acts when cookies are missing, and a way to add custom skip filters based upon for instance the URL.

THese are just random ideas and plans that I’ve got at the moment, I haven’t begone coding it yet, but it’s definetely something I’m going to do at some point. I’ll welcome any input if you have any.