By way of review, I've pushed a new branch, dup-warning-#9, whereby I've rebased this branch onto mbland-optimized from #8. First it fixes a bug whereby no warning was emitted when a test case appeared in between the two duplicates (the pipeline needed sort in between grep and uniq), but otherwise maintains parity with the original while making changes to improve readability and performance.

Each individual commit message explains the rationale for each change. The final message shows that using a while loop instead of a grep pipeline improves performance significantly (the test suite runs ~9% faster on macOS, ~19% faster on Windows under VMWare).

@BvBerkum Let me know if you have any questions or concerns, or how you'd like to proceed. Feel free to cherry-pick my commits onto your branch, or just copy the code. I still hope to merge #8 first, though it's not strictly necessary.

cc: @btamayo

OK, #8 has been merged, and I've rebased dup-warning-#9 upon it. The conflict in this branch is just where #8 and this PR both added a new test case to the end of test/bats.bats.

Afterwards, I began thinking a bit more about the performance impact. I really just picked up this issue to refamiliarize myself with the BATS core code. Also having recently tried the optimized branch, I've been trying to get a bit more conscious about the resource footprint. E.g. I use a bats dry-run in my GIT pre-commit to verify the test cases parse OK. And on a modern macbook or cloud server its easy to forget what a little shell scripting can cost.. Anyway.

I will return to the code during the week or next weekend probably, and look at your fixes @mbland. And try see about any performance hit in addition.

@BvBerkum Have you the bandwidth to bang on this this weekend? Don't want to rush you, but I'd like to keep the momentum towards v1.0.0 going.

Also, to the point about performance: I didn't start thinking about it until I had several hundred test cases for mbland/go-script-bash that were taking about an hour to run on Windows—then I thought about it a lot. ;-) Certainly the optimization techniques I applied to Bats would be overkill in most scripts, but for a test framework that executes DEBUG traps and other frequently-looping operations, they can make the difference between people writing and running tests, or deciding the wait isn't worth the effort.

Hence my obsession with performance in this context, in pursuit of the larger goal of "making the right thing the easy thing."

I only found to time to mull it over a bit, but you're right, I'm too easily distracted by details. I'm talking about parsing 50 files with 300 tests or so.

Rebasing on mbland-optimized shouldn't be a problem. I'll get to it one of these days.

No worries, but two quick points:

• Rebase on master, as Fix macOS/Bash 3.2 breakage; eliminate subshells from exec-test, preprocess #8 has already been merged.
• If you'd prefer, I can file a PR from dup-warning-#9, and we can close this one. It contains your commits from this PR, with my refactors on top of it.

Hello @BvBerkum - if you've got the bandwidth to rebase @mbland's changes on to this branch please do so :)

Otherwise either @mbland or I will create a new PR for these commits some time next week so we can move towards https://github.com/bats-core/bats-core/milestone/1 :)

There you are. I'd hate to be the hold-up since I see the issues piling up again.

I'll keep out an eye for anything else to do, if I can follow what the current focus is. I'm happy with my fork and it has been easy to integrate recent upstream changes, but hopefully Bats can get some new releases out and we can get everything together and not end up with Bats dialects or insufficiently specified versions.

On top of @mbland's version, a few more tiny savings can be achieved if the inner while loop is removed. Like a couple of tens of milliseconds.

@tterranigma I think that removing the inner while loop relies on spaces not being present in the test names. Apologies if I'm incorrect, I think for that change we'd have to add a test case with "gizmo test" and "gizmo test 2" to verify. My thinking:

line="andy"
test_names=("andy 2")
if [[ " ${test_names[*]} " == *" $line "* ]]; then echo match; fi

As for this change: LGTM, /cc @mbland

@sublimino By the time the inner loop is hit, the test names are already converted to function names with dashes and underscores. The Bash variable substitutions a few lines above just capture these function names that are passed as an rfugment to bats_test_function. I think the conditional "hack" to replace the loop will work each time in this case.

@tterranigma my mistake then, sorry!

@mbland
I see a lot more changes now. I'm a bit confused what the release and/or development branch is. I'd be happy to sort some things out, but I need to know which branch to refer so all changes are tracked.

In retrospect it looks to me like the feature has significantly progressed from my initial features/duplicate-test-warning. I'm sorry for the confusion and time, please close the PR or advice. tia.

@BvBerkum Sorry to leave you hanging; things were crazy in April. You should be able to merge dup-warning-#9 into your branch, then merge the current master into it. There'll be a small conflict (a few new test cases), easy to resolve.

If you'd rather I do it, I can do it too.

@mbland done