digitalmars.D - Can we get unitests to not run with program start ?
- deadalnix (10/10) Oct 25 2016 Seriously that makes no sense, almost everybody has it own hack
- Jonathan M Davis via Digitalmars-d (18/28) Oct 25 2016 Ideally, the -unittest build would just replace main (whatever it was) o...
- deadalnix (8/20) Oct 25 2016 It is. once you need to put that in the file, there is a ton of
- Adam D. Ruppe (5/6) Oct 26 2016 Let them complain.
- Basile B. (11/17) Oct 26 2016 What would be possible is a "-fdmain" switch (force dummy main).
- pineapple (2/7) Oct 26 2016 Just using `-main` has worked well enough for me
- Basile B. (6/13) Oct 26 2016 For me too but once again I think that the issue is when you wish
- Adam D. Ruppe (7/8) Oct 26 2016 It should just be implied by -unittest!
- Nick Sabalausky (2/9) Oct 26 2016 +1
- Timothee Cour via Digitalmars-d (3/19) Oct 26 2016 +1
- =?UTF-8?Q?S=c3=b6nke_Ludwig?= (3/10) Oct 26 2016 How would a custom unit test runner such as "unit-threaded" or "tested"
- Adam D. Ruppe (3/5) Oct 26 2016 http://dpldocs.info/experimental-docs/core.runtime.Runtime.moduleUnitTes...
- =?UTF-8?Q?S=c3=b6nke_Ludwig?= (3/8) Oct 26 2016 Thanks, that should work! I misremembered this as getting called once
- Adam D. Ruppe (16/18) Oct 26 2016 Yeah, I don't love the name either.
- =?UTF-8?Q?S=c3=b6nke_Ludwig?= (5/21) Oct 26 2016 Yeah, for being able to enumerate the modules, DUB in fact generates a
- Steven Schveighoffer (4/13) Oct 27 2016 I'm with you 100%. This isn't even that hard, and doesn't require DMD
- Steven Schveighoffer (4/20) Oct 27 2016 This was pretty easy, please review/comment:
Seriously that makes no sense, almost everybody has it own hack to have a different main when building for unitests, and we look like clown. We all like to talk about language feature and all, but seriously, this kind of thing is what hurts us the most. We kind of live with it because we all have our workaround here, but really, it looks stupid to anyone that don't the tricks, and really, it should looks silly to anyone that knows the trick. Can I have my unittest build do not complain if there is no main and not run main ?
Oct 25 2016
On Wednesday, October 26, 2016 05:24:45 deadalnix via Digitalmars-d wrote:Seriously that makes no sense, almost everybody has it own hack to have a different main when building for unitests, and we look like clown. We all like to talk about language feature and all, but seriously, this kind of thing is what hurts us the most. We kind of live with it because we all have our workaround here, but really, it looks stupid to anyone that don't the tricks, and really, it should looks silly to anyone that knows the trick. Can I have my unittest build do not complain if there is no main and not run main ?Ideally, the -unittest build would just replace main (whatever it was) or run something instead of main without actually starting main, and if there were no main, it wouldn't complain about the lack thereof. That being said, using -main when unit testing libraries and declaring main in applications to look something like version(unittest) void main() {} else int main(string[] args) {...} doesn't seem like all that big a deal to me. Not ideal, but not a big deal. Regardless, I really don't think that it ever makes sense to actually run main after running the unit tests. So, in that sense, what dmd does with -unittest is downright weird. I assume that it just seemed like the easiest way to integrate them though and that that's why it was done that way. And I wouldn't mind it if it were fixed so that declaring main for unit tests was not required and that main never actually ran after the unit tests. However, I bet that if we changed it, _someone_ would complain. Someone always does, even if the change makes perfect sense and the previous behavior didn't. - Jonathan M Davis
Oct 25 2016
On Wednesday, 26 October 2016 at 05:32:51 UTC, Jonathan M Davis wrote:That being said, using -main when unit testing libraries and declaring main in applications to look something like version(unittest) void main() {} else int main(string[] args) {...} doesn't seem like all that big a deal to me. Not ideal, but not a big deal.It is. once you need to put that in the file, there is a ton of automation that can't happen anymore. Also, to anyone outside this forum, it feels like this: https://www.youtube.com/watch?v=szdbKz5CyhARegardless, I really don't think that it ever makes sense to actually run main after running the unit tests. So, in that sense, what dmd does with -unittest is downright weird.It indeed never makes any sense to do it that way.However, I bet that if we changed it, _someone_ would complain. Someone always does, even if the change makes perfect sense and the previous behavior didn't.Well obviously, but that's not a good reason.
Oct 25 2016
On Wednesday, 26 October 2016 at 05:32:51 UTC, Jonathan M Davis wrote:However, I bet that if we changed it, _someone_ would complain.Let them complain. At some point, we gotta rip off the band aid, let it go, the past is in the past.
Oct 26 2016
On Wednesday, 26 October 2016 at 05:24:45 UTC, deadalnix wrote:Seriously that makes no sense, almost everybody has it own hack to have a different main when building for unitests, and we look like clown. [...] Can I have my unittest build do not complain if there is no main and not run main ?What would be possible is a "-fdmain" switch (force dummy main). Its role would be: if a functionDeclaration named "main" is present then this normal "main" is not used (technically erased from the AST or something like that). Then acts like "-main". If I understand correctly the real problem happens when modules have to be tested but the real program "main()" must be skipped. All the other scenarios can be handled easily. For example an IDE can lookup in the AST and automatically add "-main" when the "main" declaration misses (and obviously if "-unittest" is defined).
Oct 26 2016
On Wednesday, 26 October 2016 at 08:15:44 UTC, Basile B. wrote:What would be possible is a "-fdmain" switch (force dummy main). Its role would be: if a functionDeclaration named "main" is present then this normal "main" is not used (technically erased from the AST or something like that). Then acts like "-main".Just using `-main` has worked well enough for me
Oct 26 2016
On Wednesday, 26 October 2016 at 09:22:23 UTC, pineapple wrote:On Wednesday, 26 October 2016 at 08:15:44 UTC, Basile B. wrote:For me too but once again I think that the issue is when you wish to test functions defined in the module where's main() is declared and when the main() content should be skipped. In this case stuff like "version(unittest) return 0;" must be added at the beginning of the main().What would be possible is a "-fdmain" switch (force dummy main). Its role would be: if a functionDeclaration named "main" is present then this normal "main" is not used (technically erased from the AST or something like that). Then acts like "-main".Just using `-main` has worked well enough for me
Oct 26 2016
On Wednesday, 26 October 2016 at 08:15:44 UTC, Basile B. wrote:What would be possible is a "-fdmain" switch (force dummy main).It should just be implied by -unittest! The only cast I'd be worried about is an explicit version(unittest) main() {}... then maybe the user wanted something special. And even then, meh, 99% of those cases are just fixing the broken default anyway. Otherwise, let's make the default sane.
Oct 26 2016
On 10/26/2016 09:25 AM, Adam D. Ruppe wrote:On Wednesday, 26 October 2016 at 08:15:44 UTC, Basile B. wrote:+1What would be possible is a "-fdmain" switch (force dummy main).It should just be implied by -unittest! The only cast I'd be worried about is an explicit version(unittest) main() {}... then maybe the user wanted something special. And even then, meh, 99% of those cases are just fixing the broken default anyway. Otherwise, let's make the default sane.
Oct 26 2016
+1 On Wed, Oct 26, 2016 at 7:49 AM, Nick Sabalausky via Digitalmars-d < digitalmars-d puremagic.com> wrote:It should just be implied by -unittest!On 10/26/2016 09:25 AM, Adam D. Ruppe wrote:On Wednesday, 26 October 2016 at 08:15:44 UTC, Basile B. wrote:+1What would be possible is a "-fdmain" switch (force dummy main).It should just be implied by -unittest! The only cast I'd be worried about is an explicit version(unittest) main() {}... then maybe the user wanted something special. And even then, meh, 99% of those cases are just fixing the broken default anyway. Otherwise, let's make the default sane.
Oct 26 2016
On Wednesday, 26 October 2016 at 16:12:26 UTC, Timothee Cour wrote:It looks fairly simple to do in dmd, like this (with breakage in case the user-defined main() did something useful): 1. deactivate the main functionDeclaration un funcs.d .... final bool isMain() { return ident == Id.main && linkage != LINKc && !isMember() && !isNested() && !global.params.useUnitTests; } ... 2. forces -main in params.d: ... else if (strcmp(p + 1, "unittest") == 0) { global.params.useUnitTests = true; global.params.addMain = true; } ... I see no reason to discuss much about this. People that are pro should just agree on how this should be done and someone makes a PR. Maybe the little issue would be with LDMD2 and GDMD. Since these programs are just bridges they cannot do point 1, and LDC2 and GDC would have to follow this behavior.+1 On Wed, Oct 26, 2016 at 7:49 AM, Nick Sabalausky via Digitalmars-d < digitalmars-d puremagic.com> wrote:It should just be implied by -unittest!On 10/26/2016 09:25 AM, Adam D. Ruppe wrote:On Wednesday, 26 October 2016 at 08:15:44 UTC, Basile B. wrote:+1What would be possible is a "-fdmain" switch (force dummy main).It should just be implied by -unittest! The only cast I'd be worried about is an explicit version(unittest) main() {}... then maybe the user wanted something special. And even then, meh, 99% of those cases are just fixing the broken default anyway. Otherwise, let's make the default sane.
Oct 26 2016
On Wednesday, 26 October 2016 at 21:57:59 UTC, Basile B. wrote:It looks fairly simple to do in dmd, like this (with breakage in case the user-defined main() did something useful): 1. deactivate the main functionDeclaration un funcs.d .... final bool isMain() { return ident == Id.main && linkage != LINKc && !isMember() && !isNested() && !global.params.useUnitTests; } ... 2. forces -main in params.d: ... else if (strcmp(p + 1, "unittest") == 0) { global.params.useUnitTests = true; global.params.addMain = true; } ... I see no reason to discuss much about this. People that are pro should just agree on how this should be done and someone makes a PR. Maybe the little issue would be with LDMD2 and GDMD. Since these programs are just bridges they cannot do point 1, and LDC2 and GDC would have to follow this behavior.I tried that and it doesn't work. addMain actualy just inject a main function as a mixin in the module. Yes this is a string, it is parsed and all. The problem is that this function that is injected is then not wired in as main, because isMain returns false. Any tips appreciated.
Nov 17 2016
On Friday, 18 November 2016 at 07:51:35 UTC, deadalnix wrote:On Wednesday, 26 October 2016 at 21:57:59 UTC, Basile B. wrote:Sorry to learn that. To be honest I didn't try. For now and since three or four months I use an IDE solution. It detects the main() function and sets the -main switch accordingly. Anyway I would prefer something similar directly in the compiler.It looks fairly simple to do in dmd, like this (with breakage in case the user-defined main() did something useful): 1. deactivate the main functionDeclaration un funcs.d [...] 2. forces -main in params.d: [...] I see no reason to discuss much about this. People that are pro should just agree on how this should be done and someone makes a PR. Maybe the little issue would be with LDMD2 and GDMD. Since these programs are just bridges they cannot do point 1, and LDC2 and GDC would have to follow this behavior.I tried that and it doesn't work. addMain actualy just inject a main function as a mixin in the module. Yes this is a string, it is parsed and all.The problem is that this function that is injected is then not wired in as main, because isMain returns false. Any tips appreciated.
Nov 18 2016
Am 26.10.2016 um 15:25 schrieb Adam D. Ruppe:On Wednesday, 26 October 2016 at 08:15:44 UTC, Basile B. wrote:How would a custom unit test runner such as "unit-threaded" or "tested" work in that case?What would be possible is a "-fdmain" switch (force dummy main).It should just be implied by -unittest! The only cast I'd be worried about is an explicit version(unittest) main() {}... then maybe the user wanted something special. And even then, meh, 99% of those cases are just fixing the broken default anyway. Otherwise, let's make the default sane.
Oct 26 2016
On Wednesday, 26 October 2016 at 16:08:23 UTC, Sönke Ludwig wrote:How would a custom unit test runner such as "unit-threaded" or "tested" work in that case?http://dpldocs.info/experimental-docs/core.runtime.Runtime.moduleUnitTester.1.html
Oct 26 2016
Am 26.10.2016 um 18:32 schrieb Adam D. Ruppe:On Wednesday, 26 October 2016 at 16:08:23 UTC, Sönke Ludwig wrote:Thanks, that should work! I misremembered this as getting called once per module, which would have been insufficient.How would a custom unit test runner such as "unit-threaded" or "tested" work in that case?http://dpldocs.info/experimental-docs/core.runtime.Runtime.moduleUnitTester.1.html
Oct 26 2016
On Wednesday, 26 October 2016 at 17:47:51 UTC, Sönke Ludwig wrote:I misremembered this as getting called once per module, which would have been insufficient.Yeah, I don't love the name either. But you should be able to set that in a static module ctor in your library (bonus points, even compare the old against the default and have a runtime warning about combining two incompatible test libraries) then go nuts with it. I think currently the ModuleInfo unittests property combines all of them into a single function, so to get more granularity, you have to do CT reflection, which means listing all the modules... which kinda sucks right now. It might be nice some day to make that easier. Separate out the runtime thing to return function array instead of one combined function, and perhaps some kind of assistance in walking the whole program import graph. Regardless, unittests without main() should be perfectly doable today!
Oct 26 2016
Am 26.10.2016 um 19:58 schrieb Adam D. Ruppe:On Wednesday, 26 October 2016 at 17:47:51 UTC, Sönke Ludwig wrote:Yeah, for being able to enumerate the modules, DUB in fact generates a special module if a custom unit test runner is used (well, actually it is currently tied to the "tested" runner for historic reasons, which should really be changed).I misremembered this as getting called once per module, which would have been insufficient.Yeah, I don't love the name either. But you should be able to set that in a static module ctor in your library (bonus points, even compare the old against the default and have a runtime warning about combining two incompatible test libraries) then go nuts with it. I think currently the ModuleInfo unittests property combines all of them into a single function, so to get more granularity, you have to do CT reflection, which means listing all the modules... which kinda sucks right now. It might be nice some day to make that easier. Separate out the runtime thing to return function array instead of one combined function, and perhaps some kind of assistance in walking the whole program import graph. Regardless, unittests without main() should be perfectly doable today!
Oct 26 2016
On 10/26/16 1:24 AM, deadalnix wrote:Seriously that makes no sense, almost everybody has it own hack to have a different main when building for unitests, and we look like clown. We all like to talk about language feature and all, but seriously, this kind of thing is what hurts us the most. We kind of live with it because we all have our workaround here, but really, it looks stupid to anyone that don't the tricks, and really, it should looks silly to anyone that knows the trick. Can I have my unittest build do not complain if there is no main and not run main ?I'm with you 100%. This isn't even that hard, and doesn't require DMD changes. The runtime can exit if it runs any unit tests before calling main. -Steve
Oct 27 2016
On 10/27/16 9:09 AM, Steven Schveighoffer wrote:On 10/26/16 1:24 AM, deadalnix wrote:This was pretty easy, please review/comment: https://github.com/dlang/druntime/pull/1685 -SteveSeriously that makes no sense, almost everybody has it own hack to have a different main when building for unitests, and we look like clown. We all like to talk about language feature and all, but seriously, this kind of thing is what hurts us the most. We kind of live with it because we all have our workaround here, but really, it looks stupid to anyone that don't the tricks, and really, it should looks silly to anyone that knows the trick. Can I have my unittest build do not complain if there is no main and not run main ?I'm with you 100%. This isn't even that hard, and doesn't require DMD changes. The runtime can exit if it runs any unit tests before calling main.
Oct 27 2016