<div dir="auto">Hi Nathan,<div dir="auto"><br></div><div dir="auto">I usually ensure the test outputs its inputs in case of failure and then do a text search for that.</div><div dir="auto"><br></div><div dir="auto">It's not super convenient, but definitely does the job.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 1 Nov 2019, 00:27 Nathan Ridge via clangd-dev, <<a href="mailto:clangd-dev@lists.llvm.org">clangd-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I have noticed that many of the unit tests in clangd are written in a style where a single testcase from the gtest point of view actually runs a large array of testcases. Some examples are SemanticHighlighting.GetsCorrectTokens and LocateSymbol.All.<br>
<br>
I realize this saves a bit of typing when writing the test cases, but I find it impedes debuggability.<br>
<br>
My current workflow for debugging an individual test case in a test like this, is to comment out all the other test cases in the array, and then run the test under the debugger, which is pretty laborious I was wondering, does anyone else have a better workflow?<br>
<br>
Thanks,<br>
Nate<br>
_______________________________________________<br>
clangd-dev mailing list<br>
<a href="mailto:clangd-dev@lists.llvm.org" target="_blank" rel="noreferrer">clangd-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev</a><br>
</blockquote></div>