On 30/04/2026 22:37, Graeme Geldenhuys via fpc-devel wrote:
On Thursday, 30 April 2026 18:31:57 BST Martin Frb via fpc-devel wrote:
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.
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.
https://github.com/graemeg/opdebugger/tree/master/tests/integration
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.
Yes of sorts.
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.
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).
It does not matter if GDB uses round, square or curly brackets. If it
uses , or semicolon....
With opdf you control all that formatting. You even may want to ensure
its formatted correct.
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
