Re: [go-nuts] The most performant deque of all time?

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 , deque is not only faster now, but also more efficient! Roger is such an incredible coder! Also want to say many thanks for

Re: [go-nuts] The most performant deque of all time?

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

Re: [go-nuts] The most performant deque of all time?

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

Re: [go-nuts] The most performant deque of all time?

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

Re: [go-nuts] The most performant deque of all time?

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

Re: [go-nuts] The most performant deque of all time?

FYI, I have released deque version 1.0.1 . 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 wrote:

Re: [go-nuts] The most performant deque of all time?

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

Re: [go-nuts] The most performant deque of all time?

Moved the non-unit tests to the "deque_test" package. The tests , package-wise, look as they should now. Thanks Robert for the suggestion. :-) On Mon, Nov 26, 2018 at 2:01 PM robert engels wrote: > It’s funny though, if you look at the container/ring tests, they

Re: [go-nuts] The most performant deque of all time?

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

Re: [go-nuts] The most performant deque of all time?

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

Re: [go-nuts] The most performant deque of all time?

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

Re: [go-nuts] The most performant deque of all time?

I like your thinking. Replacing UTs with asserts sounds pretty interesting to me. Let me give a good thought about it. There's clearly enormous potential, but there's also potentially many unforeseen implications. But we should continue this discussion offline or in a separate thread. I have duly

Re: [go-nuts] The most performant deque of all time?

If you re-read what you wrote you will see the problem - you weren’t setting a prev/next link correctly - the proper way test test these invariants IMO is to use asserts within the implementation itself - that way the implementation change change without breaking all of the tests. Otherwise

Re: [go-nuts] The most performant deque of all time?

It's funny because I'm not a big fan of unit testing for all the same reasons you mentioned. Impl7 , for instance, I didn't implement any unit tests as the implementation was very simple and integration

Re: [go-nuts] The most performant deque of all time?

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

Re: [go-nuts] The most performant deque of all time?

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

Re: [go-nuts] The most performant deque of all time?

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

[go-nuts] The most performant deque of all time?

Hello, I'm working on a logging system called CloudLogger 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