FYI, I have released deque version 1.0.1 <https://github.com/ef-ds/deque/blob/master/CHANGELOG.md>. Turns out there was a bug related to spared links. I really appreciate the help, Roger (@rogpeppe), for pointing out and helping fix the bug.
On Mon, Nov 26, 2018 at 8:07 PM robert engels <reng...@ix.netcom.com> wrote: > No problem, but just one last word on this… > > You have 748 lines of internal unit tests and only 295 lines of actual > code.. This IMO does not lend itself to maintainable & flexible code. If > your 295 lines needs 748 to verify its correctness something is wrong. You > have an additional 400 lines of integration tests - if those are full > coverage they should be more than enough IMO, but again, just something to > think about and to each his own. > > > > On Nov 26, 2018, at 9:56 PM, Christian Petrin <christianpet...@gmail.com> > wrote: > > Moved the non-unit tests to the "deque_test" package. The tests > <https://github.com/ef-ds/deque>, package-wise, look as they should now. > Thanks Robert for the suggestion. :-) > > On Mon, Nov 26, 2018 at 2:01 PM robert engels <reng...@ix.netcom.com> > wrote: > >> It’s funny though, if you look at the container/ring tests, they test the >> internal structure, but there are no tests of the behavior, so if the data >> structure design is not correct, the tests will pass but the operations may >> not work as expected (especially after a refactor). A case of I know what >> should happen… >> >> And then some public methods like Do()/Move() are not tested at all. >> >> >> On Nov 26, 2018, at 3:43 PM, robert engels <reng...@ix.netcom.com> wrote: >> >> My “none” looks to have been a little strong… Clearly whoever wrote the >> container package believes in testing as the OP. A more in-depth review >> shows other packages with similar “private tests”, but typically they seem >> to be testing the public API only. Then there are packages like sync that >> have no private tests… >> >> It appears there is no standard in the stdlib as far as this goes :) >> >> Like I said, it is my opinion, and I’m sure others feel differently. It’s >> served me well - mileage may vary. >> >> On Nov 26, 2018, at 3:32 PM, Dan Kortschak <dan.kortsc...@adelaide.edu.au> >> wrote: >> >> container/ring (a arguably non-idiomatic stdlib package does indeed >> contain this kind of test). It also does not have in code asserts, >> which are something that I've found to be very rare in Go code. >> >> On Mon, 2018-11-26 at 12:09 -0600, robert engels wrote: >> >> I am just offering, and many would disagree, that unit tests that >> like are brittle and not worthwhile. I don’t see them in the Go >> stdlib for major packages, but I could be wrong. >> >> My thought on this is that if you are testing the nitty details of >> the implementation, you need to get that “correct” twice - and if it >> is failing, you don’t really know which one is wrong… This is >> especially problematic as things are refactored - all of those types >> of tests break. >> >> I’m of the opinion - test the behavior comprehensively, and expose >> the expected usage (and corresponding design) there. >> >> >> On Nov 26, 2018, at 11:58 AM, Christian Petrin <christianpetrin@gma >> il.com> wrote: >> >> 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.co >> m <mailto:reng...@ix.netcom.com <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 <christianpetrin@g >> mail.com <mailto:christianpet...@gmail.com <christianpet...@gmail.com>>> >> wrote: >> >> Hello, >> >> I'm working on a logging system called CloudLogger <https://githu >> b.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 >> <https://github.com/golang/go/issues/27935> >> Deque package: https://github.com/ef-ds/deque >> <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 >> <mailto:golang-nuts+unsubscr...@googlegroups.com >> <golang-nuts+unsubscr...@googlegroups.com>>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. >> >> >> >> -- >> Thanks, >> Christian >> >> -- >> CRICOS provider code 00123M >> >> >> >> -- >> 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 > > > -- 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.
