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 -- 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.
