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.com> 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-47157259 > <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 (christianpet...@gmail.com > <mailto:christianpet...@gmail.com>) wrote: > >> 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 >> <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 <christianpet...@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 <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 >> >> >> >> -- >> 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>. > -- 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.
