« first day (2122 days earlier)      last day (213 days later) » 

12:00 AM
RELOAD!
[Minesweeper] Games Played: 179, Bombs Used: 131, Moves Performed: 20497, New Users: 48
RELOAD!
[rubberduck-vba/Rubberduck] 25 issue comments
 
 
9 hours later…
8:54 AM
If I make unit tests and RD builds successfully after, does that mean the inspection passed them? Or could it mean I messed up something with the unit test setup?
It seems like it was too easy. Several steps I didn't verify to make sure they were doing what I assumed they were but I was getting bored so I just built to see what happened.
I've found that typically omitting several steps like that ends up in a ton of problems, which is why I feel like I had to have messed up
 
Building in VS will not run unit tests.
 
There we go, that sounds better.
 
To run them, you select the desired option under the Test menu.
 
Test explorer?
nvm is obvious
 
BTW, usually the best order to do things when you implement something is set up skeleton of the appropriate class -> write tests -> run tests and see them fail_ -> implement -> run tests again.
Be warned, running all tests taked a bit less than 7 minutes.
 
8:59 AM
Oh set up tests before you start implementing members?
 
It is called test driven development (TDD).
 
I decided to run just the ones for the inspection.
 
It ensures that the code will be testable and that the tests actually test anything.
 
Oh so basically you use the tests to articulate how you view the class being used
That actually makes a lot of sense.
 
The usual mantra is Do not trust a test you have never seen to fail.
I also do not always adhere to that.
Pure TDD would write the tests before anything alse.
However, without even the skeleton, it is super inconvenient and does not tell you much more than that you have not set up anything.
 
9:02 AM
okay that
is what I was going to ask
sometimes it feels like it's right to start implementing if you have a good idea or something
get it down is more priority
but as a general rule I'll try to incorporate it as much I can
 
Dong tests up front usually helps to actually test all cases you want to test.
 
And give you a place to jot them down when you think of new ones.
Anyways I figured out how to run the tests and they all failed with a parser error, which is much more along the lines of what I was expecting.
 
For the example of your test, you would test that it triggers for 10, does not trigger for 9, does not trigger for 9, if two belong to the same property, does not trigger for 11 if three belong to the same property and maybe the ignore case. However, the latter is actually covered by the base class.
 
clearly my VBA is rusty :/
 
Do the opening and closing parts of the members match?
 
9:06 AM
Can the only thing you get out of the testing framework is whether or not there was a result?
 
You also get the message what failed.
 
I was trying to save space by only having three members per test and just verifying that it read the correct count.
Can I get a non-result back?
@M.Doerner probably not lol
 
You can also get Inconclusive as result.
The TestExplorer shows it as NotRun for some reason.
It lacks a specific category for it.
 
okay maybe I'll switch then
I guess I was thinking of when it was a setting
wasn't sure how to account for the trigger amount being variable
 
I generally have the test explorer as one tab in the bottom, together with the error and output windows.
Once you actually use a setting, you will have to inject an IConfigurationProvider, or whatever it is called.
Just look at the other implementations of the base class using global information.
 
9:11 AM
right
I figured that was going to lead me to trying to actually implement the setting part
and I felt it would probably not end as well as I wanted it to
 
Then, in the test, you use a Mock<IConfigurationProvider> for that and set it up to provide whatever setting you want in your test.
 
okay that makes perfect sense ty
also is there a way to test without having to rebuild the solution each time?
 
To be able to just mock dependencies is one reason we do DI.
No
 
guess I'll have to shape up then
also I realized parse error was coming from using a tuple wrong
 
Well, it has to have the latest state to test on.
 
9:14 AM
I thought a List<tuple> would let you change the value of List[i].ItemN
 
BTW, when you run tests, it will build automatically if necessary.
 
but it apparently doesn't?
oh I see tuple is immutable
ok
also that is good to know
seems like it built quicker the second timr
 
9:29 AM
only one other inspection uses the global information with results base?
 
I think there should be two atm.
Might be that one uses the version with additional result properties.
 
9:45 AM
@M.Doerner yeah ShadowedDeclarationInspection
then three for the regular unless you meant two because meaningful names and hungarian notation are so similar?
also i fixed it and it passed all five tests
i had it check for standard members, event, property let/set only, property get only, and property with both set and get
that covers what you said above
going to push it i think please go easy on me
unless you want me to try and actually get the global class part implemented first
i just did enough to let the unit testing inject the mock so I could use a lower setting limit than the default
i.e. made a second constructor intended for use only with the unit test
did not switch the base implementation or do whatever else is needed to add the setting to the app
i guess i can do that before pushing if i find the energy
 
I think the settings part can be an enhancement later on.
 
10:12 AM
okay
i left a note for that + the quick fix
i think i might come back to it pretty quickly though
they seem like important things to understand
wtf
i lost all my changes
 
What exactly did you do before losing them?
 
i staged them in git gui then reset because there was a comment i forgot to take out
i thought reset unstaged without changing files
clearly git gui option for it is the one that does
i should probably stop using git gui?
 
reset does not mean cancel stage.
 
the link - first option made it sound like that is what it was doing
 
reset means bring back to the state of the specified/prior commit.
 
10:25 AM
is gitlab not affiliated with github?
that link is really unambiguous
in not saying what you are saying
 
Hm
 
10:47 AM
well i will take it as a lesson
thankfully i remembered what i did enough
so i have it back
 
11:03 AM
[rubberduck-vba/Rubberduck] build for commit a3197414 on unknown branch: 61.47% (target 0%)
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/5445?src=pr&el=h1) Report
> Merging [#5445](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/5445?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/e56bb88f4eab28c1fbeb5146403ba9da37a52d39?src=pr&el=desc) will **decrease** coverage by `0.01%`.
> The diff coverage is `50%`.


```diff
@@ Coverage Diff @@
## next #5445 +/- ##
==========================
 
11:17 AM
[rubberduck-vba/Rubberduck] build for commit 7e6294f6 on unknown branch: AppVeyor build succeeded
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/5445?src=pr&el=h1) Report
> Merging [#5445](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/5445?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/e56bb88f4eab28c1fbeb5146403ba9da37a52d39?src=pr&el=desc) will **increase** coverage by `0.03%`.
> The diff coverage is `92.5%`.


```diff
@@ Coverage Diff @@
## next #5445 +/- ##
========================
[rubberduck-vba/Rubberduck] build for commit 7e6294f6 on unknown branch: 61.51% (target 0%)
[rubberduck-vba/Rubberduck] build for commit 7e6294f6 on unknown branch: 92.5% of diff hit (target 60%)
[rubberduck-vba/Rubberduck] build for commit 7e6294f6 on unknown branch: 61.51% (target 0.00%)
 
 
3 hours later…
 
5 hours later…
9:13 PM
WP plan upgraded from "Free" to "Premium" - the ads are gone, and I'm revamping the blog as I'm re-tagging and sorting out the articles and building an actual ToC
 
@Duga As far as I understand the dialog setup, it is the combination of RefactoringModel and presenter interface that determines the presenter we get from the RefactoringPresenterFactory and thus the dialog.
So, different dialogs get different marker interfaces.
 
 
1 hour later…
11:17 PM
Howdy just saw the tweet Matt and took a peek at the new blog style nice and sassy! meaning no ads good job :)
 
only the ads are gone, styling/revamping is still in progress - oh and we'll have a "donate" button, too (just finishing PayPal setup, waiting for the new dedicated bank account to show up in my banking app so I can link it to PayPal), because this "Premium" plan isn't free ...hopefully that'll make a penny or two between now and next year when the renewals come
 
 
 
#WhatAmIDoingWrongAgain
 
[rubberduck-vba/Rubberduck] web-flow pushed commit 17cad285 to paypal-button: wrapped form in a div
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/5448?src=pr&el=h1) Report
> :exclamation: No coverage uploaded for pull request head (`paypal-button@17cad28`). [Click here to learn what that means](https://docs.codecov.io/docs/error-reference#section-missing-head-commit).
> The diff coverage is `n/a`.
 

« first day (2122 days earlier)      last day (213 days later) »