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