Hi Robert, the deque has unit, integration and API tests. The unit tests, I agree, are hard to follow as they have to check all internal properties to make sure the code is doing what it is supposed to do (keep a well formed ring linked list during all steps). Given their nature (unit tests), the only way to access the internal deque variables is to have them in the same package.
Regarding the other, API and integration tests, I agree 100%. They should be in the dequeue_test package as they are not supposed to access (or know of) any of the deque internal variables. I'll move these tests to a different file in the dequeue_test package. Really appreciate the suggestion (correction, really). Thanks, Christian On Mon, Nov 26, 2018 at 9:42 AM robert engels <reng...@ix.netcom.com> wrote: > Just an FYI, IMO your testing is incorrect. > > Your tests should be in a package dequeue_test so that they cannot access > the internal details. This makes them brittle and hard to follow. > > For reference, look at the Go stdlib sync/map.go and sync/map_test.go. All > of the tests are in sync_test for all of the structs/methods. > > > On Nov 26, 2018, at 10:59 AM, Christian Petrin <christianpet...@gmail.com> > wrote: > > Hello, > > I'm working on a logging system called CloudLogger > <https://github.com/cloud-logger/docs> and to cut to the chase, > CloudLogger needs an unbounded in-memory queue. The idea is to use the > queue as a sequential data store. As there's no telling beforehand how much > data will need to be stored, the queue has to be able to scale to support > large amounts of data, so CloudLogger needs an unbounded queue, a very fast > and efficient one. > > Noticing Go doesn't offer an unbounded queue implementation, I came up > with an idea to build a queue based on linked slices. > > I was so impressed with the results that I decided to spend some time > researching about other queue designs and ways to improve it. I'm finally > done with the research and I feel like the new queue is worth being > considered to be part of the standard library. > > So please take a look at the issue. All suggestions, questions, comments, > etc are most welcome! > > Due to many suggestions, I have deployed the deque as a proper external > package. In order to help validate the deque and get it into the standard > library, I need to somehow get people to start using it. If you are using a > queue/stack/deque, please consider switching to the new deque. Also if you > know someone who is using a queue/stack/deque, please let them know about > the deque. > > I'm extremely interested in improving the queue and I love challenges. If > you suspect there's a possibly better design or a better, more performant > and balanced deque implementation out there, please let me know and I'm > very glad to benchmark it against deque. > > Proposal: https://github.com/golang/go/issues/27935 > Deque package: https://github.com/ef-ds/deque > > Thanks, > Christian > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > > -- Thanks, Christian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
