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 <christianpet...@gmail.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.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 <christianpet...@gmail.com >> <mailto:christianpet...@gmail.com>> wrote: >> >> Hello, >> >> I'm working on a logging system called CloudLogger >> <https://github.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> >> Deque package: 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>. >> 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.
