[bug#31788] [PATCH] tests: Honor the return value of 'start-service'.

[ludo@gnu.org (Ludovic Courtès)]

Clément Lassieur <clement@lassieur.org> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi Clément,
>>
>> Clément Lassieur <clement@lassieur.org> skribis:
>>
>>> Since commit dc7b3e56337ee9d8dcd8fe7d5cab71ef536d024f, 'start-service' returns
>>> the Shepherd's representation of the service as a sexp, and '#f' if the
>>> service fails to start.  Also, it doesn't throw an exception when the service
>>> fails to start, so relying on an exception instead of relying on its return
>>> value is a false positive.
>>
>> Looking at ‘invoke-action’ (used by ‘start-service’) in (gnu services
>> herd), it seems that an exception is raised upon error:
>>
>>       (('reply ('version 0 x ...) ('result y) ('error error)
>>                ('messages messages))
>>        (for-each display-message messages)
>>        (raise-shepherd-error error)
>>        #f)
>
> But that's for Shepherd errors.  When a service fails to start, it's not
> a Shepherd error, so if my understanding is correct '(cont result)'
> should be called.  With result being '#f'.

Oh, you’re right, sorry for the confusion.  So on success
‘start-service’ returns a truth value, and we’re fine.

I’m not entirely sure about things like this:

-          (test-eq "service running"
-            'running!
+          (test-assert "service running"
             (marionette-eval
              '(begin
                 (use-modules (gnu services herd))
-                (start-service 'mcron)
-                'running!)
+                (start-service 'mcron))
              marionette))

‘start-service’ in this case returns a number (the PID), and I think
‘test-assert’ reports a failure when the value is not exactly #t.  Isn’t
it the case?

Ludo’.