Is it somehow possible to only run the unittests of a single d file within a dub project? Of course without resorting to typing the complete commandline with all versions includes switches etc.

On Sunday, 4 March 2018 at 10:43:06 UTC, Arjan wrote:
> Is it somehow possible to only run the unittests of a single d file within a dub project? Of course without resorting to typing the complete commandline with all versions includes switches etc.

In Coedit yes.

1/ The path to the other source (usually the <leading path>/src/ or <leading path>/source/) folder must be registered in the library manager.
2/ Menu "Compilation" item "Run file unittests", which test the module that have the focus in the editor.


Relevant manual page:

- http://bbasile.github.io/Coedit/features_runnables#other (The action Run file unittest is almost the same thing as a runnable, except that -unittest is added to the switches byt the IDE).
- http://bbasile.github.io/Coedit/widgets_library_manager : dependencies for single  module to be run or executed must be reistered here.

And finally i can say that it works fine since i use this system for years.

On Sunday, 4 March 2018 at 11:38:37 UTC, Basile B. wrote:
> On Sunday, 4 March 2018 at 10:43:06 UTC, Arjan wrote:
>> [...]
>
> In Coedit yes.
>
> 1/ The path to the other source (usually the <leading path>/src/ or <leading path>/source/) folder must be registered in the library manager.
> 2/ Menu "Compilation" item "Run file unittests", which test the module that have the focus in the editor.
>
>
> Relevant manual page:
>
> - http://bbasile.github.io/Coedit/features_runnables#other (The action Run file unittest is almost the same thing as a runnable, except that -unittest is added to the switches byt the IDE).
> - http://bbasile.github.io/Coedit/widgets_library_manager : dependencies for single  module to be run or executed must be reistered here.
>
> And finally i can say that it works fine since i use this system for years.

Actually i realize that i only work well when the project is a library.
And this is probably a limitation i could remove in the IDE.

On Sunday, 4 March 2018 at 12:22:35 UTC, Basile B. wrote:
> On Sunday, 4 March 2018 at 11:38:37 UTC, Basile B. wrote:
>> On Sunday, 4 March 2018 at 10:43:06 UTC, Arjan wrote:
>>> [...]
>>
>> In Coedit yes.
>>
>> 1/ The path to the other source (usually the <leading path>/src/ or <leading path>/source/) folder must be registered in the library manager.
>> 2/ Menu "Compilation" item "Run file unittests", which test the module that have the focus in the editor.
>>
>>
>> Relevant manual page:
>>
>> - http://bbasile.github.io/Coedit/features_runnables#other (The action Run file unittest is almost the same thing as a runnable, except that -unittest is added to the switches byt the IDE).
>> - http://bbasile.github.io/Coedit/widgets_library_manager : dependencies for single  module to be run or executed must be reistered here.
>>
>> And finally i can say that it works fine since i use this system for years.
>
> Actually i realize that i only work well when the project is a library.
> And this is probably a limitation i could remove in the IDE.

NVM, will be in Coedit 3.6.4[1]. This will work for applications sources too, assuming the main in is app.d

[1] https://github.com/BBasile/Coedit/commit/f8c5e686c8c6aaa7dc2c770121767e3e59806a0e

Thanks for givin me the idea original poster.

On Sunday, 4 March 2018 at 16:51:06 UTC, Basile B. wrote:
> [1] https://github.com/BBasile/Coedit/commit/f8c5e686c8c6aaa7dc2c770121767e3e59806a0e
>
> Thanks for givin me the idea original poster.

Guess I will have to give coedit another try then.. ;-)

So you do use dub behind the scenes so it seems? Care to elaborate a little on how you achieved this?

On Monday, 5 March 2018 at 09:19:52 UTC, Arjan wrote:
> On Sunday, 4 March 2018 at 16:51:06 UTC, Basile B. wrote:
>> [1] https://github.com/BBasile/Coedit/commit/f8c5e686c8c6aaa7dc2c770121767e3e59806a0e
>>
>> Thanks for givin me the idea original poster.
>
> Guess I will have to give coedit another try then.. ;-)
>
> So you do use dub behind the scenes so it seems? Care to elaborate a little on how you achieved this?

No this feature is based on dmd / ldmd or gdmd. It's a kind of rdmd.
Basically the current source for the editor which has the focused:

- is auto saved or saved to a temp file if it's a new module
- its shebang is parsed to detect custom options (such as "-release" or "-g")
- is optionally scanned to detect if the option "-main" has to be passed or not.
- is optionally scanned to detect all "import ...;". The results are used to detect what are the deps in a database based on the "library manager". From the deps  -I<path> and *.a or *.lib or *.d are detected.
- if the option for autodetection is not checked then the whole libman is passed as import path, additional source or libs to link.
- everything is compiled
- result is run.

The same happens when using the action "run file unittest", just -unittest is added to the compiler arguments.

Beside Coedit also support DUB single file package but nothing is done by the IDE, just DUB is called and the IDE let him doing his job ;)

On Sunday, 4 March 2018 at 10:43:06 UTC, Arjan wrote:
> Is it somehow possible to only run the unittests of a single d file within a dub project? Of course without resorting to typing the complete commandline with all versions includes switches etc.

You could use unit-threaded:

http://code.dlang.org/packages/unit-threaded

You'd still need to build everything, but `dub test` would take care of that. I started working on, and need to get back to, a way of only building one module and needed dependencies.

Atila

On Monday, 5 March 2018 at 11:26:37 UTC, Atila Neves wrote:
> On Sunday, 4 March 2018 at 10:43:06 UTC, Arjan wrote:
>> Is it somehow possible to only run the unittests of a single d file within a dub project? Of course without resorting to typing the complete commandline with all versions includes switches etc.
>
> You could use unit-threaded:
>
> http://code.dlang.org/packages/unit-threaded
>
> You'd still need to build everything, but `dub test` would take care of that. I started working on, and need to get back to, a way of only building one module and needed dependencies.
>
> Atila

Thanx will take a look at it and yes that would be exactly what I was after!