FYI, we just released deque [v1.0.2]( https://github.com/ef-ds/deque/blob/master/CHANGELOG.md). Due to the amazing contributions of Roger Peppe <https://github.com/rogpeppe>, deque is not only faster now, but also more efficient! Roger is such an incredible coder!
Also want to say many thanks for the support. I'm blown away by the amount of views and clones already! :-) On Tue, Nov 27, 2018 at 8:42 PM Robert Engels <reng...@ix.netcom.com> wrote: > The fmt_test.go is a perfect example. It only tests the public API so the > tests are extensive. > > There is a huge difference between logic attempting to verify the internal > logic and state, versus tests that exercise the public api extensively. > > I think I’ve talked the point to death... to each his own. Happy coding! > > > On Nov 27, 2018, at 9:58 PM, Dan Kortschak < > dan.kortsc...@adelaide.edu.au> wrote: > > > > Sometimes the code used in production is more concise or clever in > > order to be more performant. The testing code then is more verbose in > > order to do the work in a less efficient but clearer way. This may > > result in the test code being longer than the tested code. In addition > > to this there may be many lines describing test cases in tables; take > > for example fmt where the fmt_test.go file is 1522 sloc while the > > format.go and print.go files that it tests are together 1312 sloc, > > similarly in json where decode_test.go is 1920 sloc and decode.go is > > 971. > > > > Dan > > > >> On Tue, 2018-11-27 at 21:40 -0600, robert engels wrote: > >> If the tests are internal, you technically needs tests for the tests > >> - based on LOC there is more logic in the tests to “be correct” than > >> actual lines of code. > >> > >> That is a snowballing problem if you ask me… If the code needs 3x LOC > >> for “internal tests”, its a sign that the actual code is too complex > >> / poorly designed / structured. > >> > >> Public API tests are a completely different thing, as their logic is > >> documented by the public API. > >> > >> Again, JMO. > >> > >>> > >>> On Nov 27, 2018, at 7:55 PM, Freddy Martinez <freddy311...@gmail.co > >>> m> wrote: > >>> > >>> Sorry Chris, I haven’t seen the code + tests, I don’t think that > >>> having x lines of code and 2x lines for test code is a problem, in > >>> fact, if you use TDD this is very common because you’ll have a > >>> looot of line code in your tests because this is how TDD works… > >>> > >>> Why is this an issue ? > >>> > >>> Again, I haven’t seen the code, but IMHO, I don’t think that there > >>> is a limit in the number line of code in your tests. > >>> > >>> Regards > >>> > >>> > >>> ============================================= > >>> Freddy Martínez García > >>> Software Engineer > >>> B.S. Computer Science > >>> LinkedIn: https://ar.linkedin.com/in/freddy-martinez-garcia-4715725 > >>> 9 <https://ar.linkedin.com/in/freddy-martinez-garcia-47157259> > >>> > >>> “If you give someone a program, you will frustrate them for a day; > >>> if you teach them how to program, yo will frustrate them for a > >>> lifetime.” > >>> > >>> David Leinweber > >>> > >>> On 27 November 2018 at 22:20:25, Christian Petrin (christianpetrin@ > >>> gmail.com <mailto:christianpet...@gmail.com>) wrote: > >>> > >>>> > >>>> FYI, I have released deque version 1.0.1 <https://github.com/ef-d > >>>> s/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 <rengels@ix.netcom. > >>>> com <mailto: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 <christianpetrin@ > >>>>> gmail.com <mailto: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 <rengels@ix.netco > >>>>> m.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 <rengels@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.kortschak@a > >>>>>>> delaide.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 <christi > >>>>>>>>> anpetrin@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 <rengels@ > >>>>>>>>> ix.netcom.co <mailto:reng...@ix.netcom.co> > >>>>>>>>> m <mailto:reng...@ix.netcom.com <mailto:reng...@ix.netc > >>>>>>>>> om.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 <chris > >>>>>>>>>> tianpetrin@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 <h > >>>>>>>>>> ttps://githu <https://githu/> > >>>>>>>>>> b.com/cloud-logger/docs <http://b.com/cloud-logger/do > >>>>>>>>>> cs>> 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+unsubscribe@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/o > >>>>>>>>>> ptout <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 > >>>> > >>>> > >>>> -- > >>>> 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>. > >>>> For more options, visit https://groups.google.com/d/optout > >>>> <https://groups.google.com/d/optout>. > > -- > > CRICOS provider code 00123M > > > > -- 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.
