Bug 5587 – Use __LINE__ to pick number in unittest block names

At the moment, we can't name unit tests. Ideally we could, but for now, we can't. And this is a big problem in that any exceptions that are thrown from a function called directly or indirectly by a unittest block ends up with a fairly useless stack trace because the function generated from the unittest block is something like _unittest1298, which gives absolutely no clue as to which unittest block it's for. I have no idea how that number is generated, but as far as I can tell, it's useless. Don suggested that we use __LINE__ to generate that number so that it actually _is_ meaningful. So, I'm opening this enhancement request for that to be done. I still think that we should have named unittest blocks at some point (e.g. unittest(testName) {}), but using __LINE__ in the name would be a big help.

It's a good idea. Actually, file and line.

Um, have to be careful about two unittests on the same line!

(In reply to comment #2) > Um, have to be careful about two unittests on the same line! __COLUMN__ ftw!

I think this request is a very good idea. (In reply to comment #2) > Um, have to be careful about two unittests on the same line! Why? Either combine the functions into one, or disallow that possibility (shouldn't be too disruptive I would think).

(In reply to comment #4) > > Um, have to be careful about two unittests on the same line! > Why? Either combine the functions into one, Which introduces a complex special case. > or disallow that possibility > (shouldn't be too disruptive I would think). D has no similar dependencies on line endings, this would be a bizarre exception.

(In reply to comment #1) > It's a good idea. Actually, file and line. "File" is not needed because the module's name is already part of the mangled name of the unittest.

(In reply to comment #5) > > Why? Either combine the functions into one, > > Which introduces a complex special case. Actually, you are right, this solution requires complex rewriting of the code. Probably not worth the effort. > > or disallow that possibility > > (shouldn't be too disruptive I would think). > > D has no similar dependencies on line endings, this would be a bizarre > exception. It's not that bizarre. It doesn't even have to go into the grammar. All that happens is you have the auto-namer name the two unit tests the same, and let the semantic pass reject it (duplicate function definition). This can easily be explained to the user in the docs. Besides, who puts two function blocks on the same line anyways? I've seen people write one or two statement functions on the same line, but never more than one of those on the same line (except in obfuscation contests, but who writes unit tests for those?) My prediction is that if you did this you will never ever hear a complaint about it :)

(In reply to comment #5) > (In reply to comment #4) > > > Um, have to be careful about two unittests on the same line! > > Why? Either combine the functions into one, > > Which introduces a complex special case. > > > or disallow that possibility > > (shouldn't be too disruptive I would think). > > D has no similar dependencies on line endings, this would be a bizarre > exception. Yah. Probably a simple practical solution is to define a name for the unittest depending on __FILE__ and __LINE__ for single unittests, and to add a count only for several unittests on the same line. This makes the common case simple and the exceedingly rare exception handled with panache. For example: unittest { a(); } unittest { b(); } unittest { c(); } The first unittest is "unittest at foo/bar/baz.d:238", the second unittest is "unittest #1 at foo/bar/baz.d:239", and the third is "unittest #2 at foo/bar/baz.d:239". That takes care of everything. BTW Walter I appreciate you giving a look to this. It's a simple addition that would drastically improve the conviviality of unittests.

Created attachment 1009 Add __LINE__ to the unittest's uniqueId If the purpose is only let the user identify which line the unittest is on, adding the __LINE__ to its uniqueId is enough.

Very nice. Why patch and not pull request?

(In reply to comment #10) > Very nice. Why patch and not pull request? Just to get see if this is good enough. Anyway, DMD pull #264. https://github.com/D-Programming-Language/dmd/pull/264

Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/8f478ace129b50844aed91b5be82a78238cbb1dc Bug 5587: Give unit test name by __LINE__. This commit appends 'Lxx' to the unittest's mangled name. The user can get the line number from the traceback: 5 x 0x000091c5 onAssertErrorMsg + 73 6 x 0x00009206 onUnittestErrorMsg + 26 7 x 0x00013199 _d_unittestm + 45 8 x 0x000019d7 void x.__unittest_fail(int) + 27 9 x 0x00001a0a void x.__unittestL13_1() + 46 ^^^ line 13 https://github.com/D-Programming-Language/dmd/commit/d3669f79813ba314768daf43eb1bfa90dac4c4a1 Merge pull request #264 from kennytm/bug5587_unittestWithLine Bug 5587: Give unit test name by __LINE__.

Added patch to D1, too.

Woohoo!

Could we also change Lexer::uniqueId to not append "_1" to the first symbol generated? I mean instead of "symbol_1", "symbol_2", ... it should generate "symbol", "symbol_1", ... That way most unittests will have nicer names.