Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Value should probably be a `Set` then!


What if it's a repeated field of a protocol buffer? Parse it into a set and then check it? That's exactly what `assertThat(expected).containsInAnyOrder(foo,bar,baz);` is doing anyway.


I'm not very familiar with protobuf, but in searching, repeated field seems to have list- or set-like semantics, so yeah, I'd parse the value into a list or a set and compare it to a list or a set.


If you were going to work with protocol buffers frequently you'd probably quickly find yourself doing this over and over, and would then create the aforementioned `assertThat(expected).containsInAnyOrder(foo,bar,baz);`.


There are ordered sets, immutable sets... infinite sequences, lazy lists, sometimes collections are hairy to test.


If find that if I am trying to test values that are not 'fully realizable' (infinite, lazy, etc) there's typically a temporal aspect involved, and I have a 'mock clock and timer' implementation so that I can call a `time.advance(t)` from within my tests and time advances in my system under test. This works because (as OP also noted) I only use my own mockable abstractions for answering the question 'what time is it?' and for instructing the system 'call me back at time t'. The net effect being I can fully define the behavior of the system within an arbitrary window of time—and collect the resulting values or behavior into some data structure which encodes what happened and when, and then compare it against expected results.

Re immutable: the values you're getting from your system under test and the expected values you're constructing in tests should always be immutable!




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: