<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 30/04/2026 22:37, Graeme Geldenhuys
via fpc-devel wrote:<br>
</div>
<blockquote type="cite"
cite="mid:10544622.oftP80ogcF@graeme-linux-desktop">
<pre wrap="" class="moz-quote-pre">On Thursday, 30 April 2026 18:31:57 BST Martin Frb via fpc-devel wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">Not exactly what I meant... If you do it this way, then you can only
match the entire output against one expectation for it all.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
Maybe not 100% what you described, but it sound like it's very similar in
concept to my integration tests (not unit tests) I defined for OPDF's cli
debugger.
<a class="moz-txt-link-freetext" href="https://github.com/graemeg/opdebugger/tree/master/tests/integration">https://github.com/graemeg/opdebugger/tree/master/tests/integration</a>
Maybe there is something useful you could reuse.
* Integration tests are trigger by running the 'run_test.sh' script.
* Each test has *.commands as input and *.expected as what it expects.
* The test run creates a *.diff file. If that file is not 0 bytes, something
broke.
</pre>
</blockquote>
<br>
Yes of sorts.<br>
<br>
Only an exact diff is not necessary the best test. We aren't in
charge of gdb, and if we want to cover a range of versions, then we
can't always predict the exact formatting. Nor do we need to.<br>
<br>
If I want to test a TPoint(10,20) works, then I just need to check
that it printed x and y with those values (and maybe that its a
record not a class).<br>
It does not matter if GDB uses round, square or curly brackets. If
it uses , or semicolon....<br>
<br>
With opdf you control all that formatting. You even may want to
ensure its formatted correct.<br>
<br>
</body>
</html>