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 > <mailto: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 >> <mailto: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 >>> <mailto: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 <http://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 >>>>> <mailto:reng...@ix.netcom.co> >>>>> m <mailto:reng...@ix.netcom.com <mailto: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 <http://mail.com/> <mailto:christianpet...@gmail.com >>>>>> <mailto:christianpet...@gmail.com>>> wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> I'm working on a logging system called CloudLogger <https://githu >>>>>> <https://githu/> >>>>>> b.com/cloud-logger/docs <http://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> >>>>>> <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> >>>>>> <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> >>>>>> <mailto:golang-nuts+unsubscr...@googlegroups.com >>>>>> <mailto:golang-nuts+unsubscr...@googlegroups.com>>. >>>>>> For more options, visit https://groups.google.com/d/optout >>>>>> <https://groups.google.com/d/optout> >>>>>> <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 >> <mailto:golang-nuts+unsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout >> <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.
