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