NCoverExplorer - input on new editing feature please
kiwidude
Jamie suggested I post in here to try to canvas some more opinions so
all feedback welcomed!
I am in the processing of adding an "Edit in VS.Net" option to
NCoverExplorer (along with some other new features). This will be an
enhanced replacement for the "Open File" right click option existing
currently. The intention is that from either a class/method node in the
coverage tree or a location within the source code being displayed with
coverage you are able to directly open that source file back in your
solution in the VS.Net IDE with the cursor at that location. This
action can be triggered by either a hotkey or a context menu.
My questions related to this are:
1. I was thinking Ctrl+E as the keyboard shortcut - are people happy
with this, have a better suggestion or should it be completely
customisable?
2. What should it do when a VS.Net instance/solution containing the
class file cannot be found (i.e. you have closed it down after your
coverage run or are running NCoverExplorer standalone)? There's a range
of possible actions here including:
(a) Perform exactly the same action as happens in Windows Explorer of
just opening it in the first VS.Net it finds (or a new instance if none
open). This is exactly what happens in the current NCoverExplorer
release if you right-click on a class/method node in the tree and
choose "Open File".
(b) Open it in an application of the user's choice - e.g. may be the
above by default but could also be "Notepad2".
(c) Some other combination?
Appreciate your input... obviously the more comprehensive the options
the longer time it may take to push it out to you but unless these
features are convenient and useful there isn't much point!
Regards,
Grant.
http://www.kiwidude.com/blog/
Jason Kemp
his blog post announcing test with coverage:
<quote>
What a killer idea! I've wanted something like this forever. I
installed it as soon as I could, and I love it. I use it at least once
an hour, more than the debugger option.
I just have one quibble\feature request. I noticed after a while that
the tests were in the coverage measurement. This skews the total
coverage for the component. Could you add a setting to include only the
project your testing, and not the tests project as well?
The default behaviour should probably to include the tests project to
keep the zero friction at zero, but perhaps an advanced setting that
would allow us to tweak which projects are passed to NCover?
</quote>
I'm not sure how NCoverExplorer does things, but NCoverBrowser, by Jeff
Key, just read the xml file; so whatever was passed to NCover.Console
was in the xml file. I know when I was hacking all this together using
batch files, I just included the assembly under test in the call to
NCover.Console. I assume NCoverExplorer works similarly. (I've only
used it with TestDriven.net).
Lothan
> all feedback welcomed!
I just tried TestDriven.NET with NCover and NCoverExplorer and it took
me a while to finally get it to work. I already use TestDriven.NET
regularly, so I installed the latest versions of NCover and
NCoverExplorer but it just reported the "supported" combinations when
selecting Test With Coverage without seeming to run any tests. I
initially thought this meant it was looking specifically for one of the
two versions of NCover mentioned, so I backed down from 1.5.2-b3 to
1.5.1-b2 with the same results. After a bit of digging, I finally
figured out that it requires administrative privileges to run. I assume
this will eventually be resolved, but it might be handy to
differentiate in the output when NCover/NCoverExplorer isn't found and
when it blows up.
kiwidude
Yes, NCoverExplorer works exactly the same way - it just uses the
entire xml file contents. Funnily enough Jamie and I have just been
trading e-mails on exactly this topic - about the most generic way that
TestDriven.Net could pick up configuration information which could
include both assemblies to profile as well as other new stuff like
Jeff's attribute exclude feature in 1.5.2. So it's definitely being
considered...
On a semi-related note I do hope to add this weekend the option to
group the coverage results by assembly, rather than by namespace (I
will likely offer both options).
Once that is in place I can then add a right-click option to an
assembly node to "Exclude" it's results, and recompute the totals...
that at least would give you a workaround and sounds quite flexible in
the long term anyways.
Regards,
Grant.
kiwidude
registry - that's going to disappear in some refactorings I have
planned this weekend. Hopefully that should resolve any issues with
local admin rights from it's viewpoint. As to why TD.Net doesn't
actually run the tests I'm not sure - I'm sure Jamie can jump in and
explain if it's not related to NCoverExplorer itself...
Regards,
Grant.
Lothan
Administrator account or by running the setup package from a command
prompt that is running as Administrator.
This generally works well, although I have noticed several applications
fail to play nicely with regular user accounts. Some install
exclusively for the account installing the software while others depend
on write access to registry keys in HKLM or folders in %ProgramFiles%.
I've even noticed a couple that delay installation steps until after
rebooting but assume the user logs in as an administrator; in effect,
the installation bombs horrendously if the user logs in with a
non-administrative account. Perhaps more curiously, the worst offenders
are commercial products rather than open source. Go figure!
Unfortunately, I know of no good way to automatically replicate
registry settings across all users. The more common solution seems to
be to write global settings into HKLM (e.g. read-only settings) and
create user settings in HKCU when the application is first run by that
account.
exor...@gmail.com
could expand the treeview to show the class-under-test directly.
currently, i'm finding that it takes some time to navigate the
namespace hierarchy to get to the class that i want to look at coverage
for. or maybe i'm just missing something.
kiwidude
code you were actually testing? TestDriven.Net I imagine would know
what unit tests you ran, but this doesn't itself mean anything as far
as determining the methods being hit which you want coverage
information for - or else maybe I'm missing something ;-)
I do have a few ideas about speeding up the navigation which will be
going in over the next few weeks. The first is to group by assembly
(done but not yet released) - that helps divide and conquer on large
projects.
I'm also thinking of adding a "smart expand" option, such that if you
expand a node it keeps automatically expanding until it finds more than
one child node. Useful if you have a deep namespace hierarchy to get
past "the fluff".
I will also likely look into preserving the list of open nodes in the
event of a file open message from TD.Net. We have already added (but
not released) functionality to reuse the existing NCoverExplorer window
when re-executing "Test with... Coverage". So if you go through "the
pain" once of expanding to the nodes you want, modify your source code
and re-run your tests you would just see the NCoverExplorer results
refreshed without you having to do anything...
Another idea I had to look into at some point was adding some simple
"filters". For instance at the click of a button hiding all nodes in
the tree with a coverage of zero %.
How do those sound to everyone - good, bad, better ideas?
Regards,
Grant.
http://www.kiwidude.com/blog/
Jamie Cansdale
very useful. You could use this feature to quickly expand and show the
class-under-test simply by selecting 'Show Covered' on the assembly
you're interested in (assuming assemblies/modules are visible in the
tree). There could even be an *option* to expand on load (you wouldn't
want active on very large projects!)
> I will also likely look into preserving the list of open nodes in the
> event of a file open message from TD.Net.
>
How about maintaining the position of the cursor in NCoverExplorer?
You could automatically expand to show any node that "contains" the
cursors line and offset.
Does that make sense?
Jamie.
Dissidence
kiwidude wrote:
> All,
>
> Jamie suggested I post in here to try to canvas some more opinions so
> all feedback welcomed!
To answer your requests.
1.) CTRL + E is cool
2.) (a) seems best
I have a few for the wish list:
1.) Ability to configure highligting colors
2.) Could NCoverExplorer somehow be made an add-in to VS.NET 2k3/2k5?
a.) With in code highlighting?
b.) Intigration between tree and code panes? (Much like your suggested
"open file" functionality)
c.) The "status" panes be pinnable ide windows/tabs (like the solution
explorer)?
d.) Hotkey binding done thru the VS.NET hotkey manager.
I know the second wish is a big one, but I wanted to make sure it was
there.
But all aside, kudos to the beautiful set of tools your two are
providing. I can't believe I lived without it!!
kiwidude
> I have a few for the wish list:
> 1.) Ability to configure highligting colors
Thanks for the input... colour customisation is a popular request and
one I have added to my list for the very next release in the next week
or two (will be 1.3.1, not included in 1.3 that I put out yesterday on
my site).
> 2.) Could NCoverExplorer somehow be made an add-in to VS.NET 2k3/2k5?
> a.) With in code highlighting?
> b.) Intigration between tree and code panes? (Much like your suggested
> "open file" functionality)
> c.) The "status" panes be pinnable ide windows/tabs (like the solution
> explorer)?
> d.) Hotkey binding done thru the VS.NET hotkey manager.
>
> I know the second wish is a big one, but I wanted to make sure it was
> there.
The add-in route is an interesting one. I did comment on the rationale
behind my decision to go external in my FAQ here:
http://www.kiwidude.com/dotnet/ncoverexplorerfaq.html
However if the demand is there from enough people then it's something I
can look into more seriously. I don't believe it is a trivial exercise
though so it's not on the plate for another month or two. I think (am
sure some extensibility gurus out there can correct me or back me up)
that you would need to subclass the IDE code window to alter it's
graphical appearance using VSIP... it's not something I've dabbled with
as yet.
Be interested to hear other peoples thoughts - if you are desperate for
a VS.Net 2003 NCover add-in there is one called NCoverViewer (on
GotDotNet from memory, although believe it was not actively being
updated). When I tried it a while ago it was a bit buggy (I made some
fixes to get it to run) and it didn't have the code highlighting which
is what you really want...
Regards,
Grant.
http://www.kiwidude.com/blog/
Jamie Cansdale
> 1.5.1-b2 with the same results. After a bit of digging, I finally
> figured out that it requires administrative privileges to run.
>
I'm curious to know how you installed NCover as a non-admin. Did you
elevate your privs, or do an admin install for all users? I believe
NCover installs some important registry entries under HKCU. If it's
displaying the "supported" combinations message then it mustn't be
able to find them.
Thanks, Jamie.
Jamie Cansdale
Thanks for your feedback. I'll contact the author of NCover and see if
we fix the limited user account issue.
If anyone else is having trouble getting NCover to work with a limited
user account, I have posted instructions on my weblog:
http://weblogs.asp.net/nunitaddin/archive/2006/02/05/437423.aspx
Thanks, Jamie.