Adds feature to use ULID in tests #444
Conversation
|
Thanks for contributing @HolyKingCrusader! :) |
| @@ -121,6 +121,9 @@ type Features struct { | |||
| // NewSubscriberReceivesOldMessages should be set to true if messages are persisted even | |||
| // if they are already consumed (for example, like in Kafka). | |||
| NewSubscriberReceivesOldMessages bool | |||
|
|
|||
| // UseULID should be set to true if ULID should be used instead of UUID for generating test IDs. | |||
| UseULID bool | |||
There was a problem hiding this comment.
@HolyKingCrusader One more idea I had was that we could make it more open for future extensions. How about if there was a TestIDFunc (or similar) field which would default to NewTestID, but any other could be supplied? (Like NewTestULID())
There was a problem hiding this comment.
@m110 Would it be used anywhere currently or just left for future use?
There was a problem hiding this comment.
I guess in scenarios like those mentioned in #226. Similar to what you originally proposed. My point is to make it a bit more open for extension rather than just a UUID/ULID choice. It's not a big deal, though, so let me know your thoughts.
To be clear, I meant having a config field like TestIDGenerator func() TestID
There was a problem hiding this comment.
I'll add it, doesn't seem to be too difficult
There was a problem hiding this comment.
Hey @HolyKingCrusader, sorry about the delay here 😅
WIth the field you added to configure the function, the UseULID would be redundant now, correct?
Also, I think the default struct tag won't work like this out of the box, you might need to manually check if it's set and default to NewTestID otherwise.
Adds feature to use ULID instead of UUID in topic name and consumer group.
Fixes #226's problem.