Thanks. The code below seems to be working for me.
Another way to run tests from http, I guess, would be using the rest interface [1].

The %unit:before annotation is interesting because it seems to allow (or can be abused) to execute multiple update operations with one "execution".

/Andy

[1] http://docs.basex.org/wiki/REST#POST_Method
[2] http://docs.basex.org/wiki/Unit_Module#.25unit:before
----------------------
(: queue async run of all tests in $dir :)
declare function local:queue-tests($dir as xs:string,$opts as map(*)){
 let $q:=``[
    declare variable  $password external;
    client:connect('localhost',
                   db:system()/globaloptions/port/xs:integer(.),
                   'admin',
                   $password)
   ! client:execute(.,'TEST "`{$dir}`"')
  ]``
  return jobs:eval($q,
                   map{"password":$opts?password},
                   map { 'cache': true()}
                 ) 
};

 local:queue-tests("C:\Users\andy\git\content-architecture\xquery\tests",
                    map{"password":"admin"})



On 5 January 2017 at 10:14, Christian Grün <christian.gruen@gmail.com> wrote:
> If something like the below is safe that would do me.
> Does this count as "a single-threaded execution of unit tests"?

Interesting approach. You could communicate with 'basexclient', or use
client:execute, and combine it with the Jobs Module, or even
xquery:fork-join (to enforce parallel execution… It’s getting nerdy).
In that case, the BaseX Server will decide when transaction can safely
be run.


> let $q:=``[
>   declare variable $basex:="C:\Program Files (x86)\BaseX\bin\basex.bat";
>
>   let $c:="C:\Users\andy\ ... \test\"
>   return proc:system($basex,("-t","."), map{"dir":$c})
> ]``
> return jobs:eval($q,(),map { 'cache': true()})
>
> /Andy
>
> On 4 January 2017 at 15:21, Christian Grün <christian.gruen@gmail.com>
> wrote:
>>
>> Hi Andy,
>>
>> Thanks for the suggestion.
>>
>> > jobs:test-uris($uris as xs:string*, $options as map(xs:string,
>> > xs:string))
>> > as xs:string
>>
>> An interesting idea… However, I think this would currently cause
>> various problems as long as a single-threaded execution of unit tests
>> is not provided. As an alternative, I could think about running unit
>> tests in parallel, even if not started from within XQuery.
>>
>> I assume that the execution of unit tests takes quite a lot of time in
>> your setup, right?
>>
>> Cheers,
>> Christian
>>
>>
>> > Asynchronously runs all functions in the specified modules that have
>> > unit
>> > annotations.A test report
>> >  is generated and  optionally cached, which resembles the format
>> > returned by
>> > other xUnit testing
>> > frameworks, such as the Maven Surefire Plugin.
>> >
>> > returns a job id
>> >
>> > /Andy
>> >
>
>