[libvirt] [PATCH 3/3] tests: deterministichash: Make hash tables arch-independent

[Bjoern Walk]

Peter Krempa <pkrempa at redhat.com> [2017-08-03, 09:47AM +0200]:
> On Thu, Aug 03, 2017 at 07:24:35 +0200, Bjoern Walk wrote:
> > Peter Krempa <pkrempa at redhat.com> [2017-08-02, 05:39PM +0200]:
> > > It turns out that our implementation of the hashing function is
> > > endian-dependent and thus if used on various architectures the testsuite
> > > may have different results. Work this around by mocking virHashCodeGen
> > > to something which does not use bit operations instead of just setting a
> > > deterministic seed.
> > 
> > This does fix the issue on S390. Anyways, I'd also like to see the tests
> > fixed that rely on the ordering of the hash table. And code that uses
> 
> The tests are fixed. They are ordered correctly to the newly mocked
> function. I don't quite get what more you'd like to see fixed.
> 

No, the test is still dependent on the ordering. Just now the mocked
hash table has deterministic ordering. This is not the same. Although it
is improbable that this will bite us somewhere, I'd still prefer a clean
solution.

> > the hash table should be tested that it does NOT rely on the ordering.
> 
> Well, that's a property of the hash table that the code should not
> depend on ordering.

Yes, and I think it would be a good idea to test for this (no idea how
to do this though).

> In fact the only part which is slightly dependant on ordering is the
> test suite. The fix to mock the ordering function properly is tested.
> 

Like with all mocks, we now test a different version of code in the test
suite. We test the code under the assumption that the hash table is
ordered deterministically. However, the real code doesn't fulfill this
assumption (rightly so, because ordering is not a property of the hash
table). There's a discrepancy.

For example, let's assume we have code that writes out an XML file from
a hash table. We do this similar to the test code in
testBlockNodeNameDetect. Writing a test against this will never fail,
because we test against the mocked hash table. However, the actual code
produces results that is dependent on the ordering.

I know this is nitpicky, but if someone down the road runs into any
problems with this it is nasty do understand.

> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list


-- 
IBM Systems
Linux on z Systems & Virtualization Development
------------------------------------------------------------------------
IBM Deutschland
Schönaicher Str. 220
71032 Böblingen
Phone: +49 7031 16 1819
E-Mail: bwalk at de.ibm.com
------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 896 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170803/bb8b7216/attachment-0001.sig>