« first day (2952 days earlier)      last day (228 days later) » 

Duga
Duga
12:04 AM
REFRESH!
[Minesweeper] 116 Games Played. 62 Bombs Used. 15656 Moves Performed. 13 New Users
[rubberduck-vba/Rubberduck] 2 issues opened. 7 issue comments
[Zomis/Games] 142 additions. 72 deletions. 5 commits. 1 issue comments
 
 
3 hours later…
Duga
Duga
3:09 AM
> Thanks for reply, so does it mean RD unit tests cannot be run through another sub in module in vb editor , but only by clicking run in host app(here RD test explorer) right.
 
 
4 hours later…
Duga
Duga
6:54 AM
> @dasvin3 yes that's basically correct. As @daFreeMan points out, you can call the methods annotated with `'@TestMethod` manually from VBA, however this wouldn't be hugely useful as the results of the tests end up in the `RubberduckAssertClass` instance and there's no easy way to extract them out. So all you would see is if the test raised an uncaught exception, not the pass/fail/inconclusive test result.

So basically no you cannot invoke RD tests in a meaningful way without the GUI.
> @dasvin3 yes that's basically correct. As @daFreeMan points out, you can call the methods annotated with `'@TestMethod` manually from VBA, however this wouldn't be hugely useful as the results of the tests end up in the `RubberduckAssertClass` instance and there's no easy way to extract them out. So all you would see is if the test raised an uncaught exception, not the pass/fail/inconclusive test result.

So basically no you cannot invoke RD tests in a meaningful way without the GUI at the m
> @dasvin3 yes that's basically correct. As @daFreeMan points out, you can call the methods annotated with `'@TestMethod` manually from VBA, however this wouldn't be hugely useful as the results of the tests end up in the `RubberduckAssertClass` instance and there's no easy way to extract them out. So all you would be able to find out is if the test raised an uncaught exception, not the pass/fail/inconclusive test result.

So no, you cannot invoke RD tests in any meaningful way without the GUI
> Thanks a lot for the replies
 
 
11 hours later…
Duga
Duga
6:22 PM
 
 
2 hours later…
SmileyFtW
SmileyFtW
7:54 PM
@HackSlash I remember when working at an aerospace company folks wanted a "scheme" for drawing numbering. I managed to quash it by noting that if they simply used the next one in line the drawings would naturally sort nicely around the date of the project and would be easily remembered because they would be (more or less) in the same group of numbers. The final nail in the coffin was when I pointed out that using a scheme will always fail because not every situation will be addressed.
Also, when "scheming" there will always be a smaller pool of numbers available.
 
HackSlash
HackSlash
++
 
SmileyFtW
SmileyFtW
Especially when the length of the field is limited... not much of a problem now, but back in the day the drawing numbers were limited to 15 or 16 characters IIRC (database design limited them - storage was expensive back then LOL)
 
HackSlash
HackSlash
8:27 PM
Right. So what if you need to identify your parts with a 8 digit field when your part numbers are 16 characters, for example?
I've got a 10 gallons of shit in a 5 gallon bucket.
Not wasting numbers is critical. They might be using 16 characters but it's not because they need to yet. It's because they didn't start counting at 1.
 
SmileyFtW
SmileyFtW
9:16 PM
They did implement a "scheme" in some ways... it wasn't pure...LOL. The program got a 2-number prefix with a single- or double-alpha that designated an engineering discipline/group... the remainder were up to the individual disciplines to dole out. Within the drawing there were additional numbers that some dolt tried to "schemify"; it was broken and unreliable for obvious reasons... <g>
 
Duga
Duga
9:37 PM
> Just thinking out loud... perhaps we could conceivably expose a test runner COM type that could orchestrate a test run from a COM client (VBA/VB6) and provide a way to expose test results? The RD test runner obviously requires RD to be loaded in the VBIDE, which is the main showstopper here (command-line execution wouldn't be loading any IDE addins)... But if there was a class that a test module could reference from the RD library... I think this could be worth exploring.
> Just thinking out loud... perhaps we could conceivably expose a test runner COM type that could orchestrate a test run from a COM client (VBA/VB6 - assuming there's still a way to access the ITypeInfo stuff from there) and provide a way to expose test results? The RD test runner obviously requires RD to be loaded in the VBIDE, which is the main showstopper here (command-line execution wouldn't be loading any IDE addins)... But if there was a class that a test module could reference from the
 
Vogel612
Vogel612
10:14 PM
@Duga @MathieuGuindon that is definitely plausible, do keep in mind that the test method discovery is currently completely based on the parser, so if that moves out of process (LSP mentions ++) that's an additional complication to beware
We do have the parser exposed via a COM object, exposing the TestEngine should be similarly complex
 
 
2 hours later…
Duga
Duga
11:49 PM
[rubberduck-vba/Rubberduck] 1608 stars vs. [decalage2/oletools] 2122 stars
 

« first day (2952 days earlier)      last day (228 days later) »