OT - Things I want in VS and C#

[jehugaleahsa]

1) The ability to inherit XML documentation. - It would be really save
me a lot of time if when I override a method, the documentation from
the base class would come up automatically. Even better, keywords that
you could place in the comments themselves as placeholders for things
like, the class name. It would be like inheriting a fill-in-the-blanks
code snippet, perhaps. This is more of a Visual Studio feature, than
anything.

2) A modifier for marking a method as test visible, but hidden
otherwise. It might shut off when in release mode or something.

private testable void myMethod(int param1) { ... }

Just some ideas. Not that I expect anyone to care.

 

[Pavel Minaev]

1) The ability to inherit XML documentation. - It would be really save
me a lot of time if when I override a method, the documentation from
the base class would come up automatically. Even better, keywords that
you could place in the comments themselves as placeholders for things
like, the class name. It would be like inheriting a fill-in-the-blanks
code snippet, perhaps. This is more of a Visual Studio feature, than
anything.

Have a look at the free GhostDoc plugin for VS (http://www.roland-
weigelt.de/ghostdoc/). After you first try it, you won't be able to
imagine how it's even possible to write XML comments without it.

2) A modifier for marking a method as test visible, but hidden
otherwise. It might shut off when in release mode or something.

    private testable void myMethod(int param1) { ... }

Consider using "internal", combined with [assembly:InternalsVisibleTo]
attribute referencing your test assembly.

Then, of course, you can always use the preprocessor to the same
effect:

#if TEST
public
#else
private
#endif
void myMethod(int param1) { ... }

and then define or not define TEST for your configurations as needed.

 

[Cor Ligthert[MVP]]

There is a website made for this kind of suggestions

http://Connect.Microsoft.Com

Cor

 

[gerry]

#2 has been around for some time :
http://msdn.microsoft.com/en-us/library/aa664622(VS.71).aspx

 

[Arne Vajhøj]

2) A modifier for marking a method as test visible, but hidden
otherwise. It might shut off when in release mode or something.

private testable void myMethod(int param1) { ... }

Consider using "internal", combined with [assembly:InternalsVisibleTo]
attribute referencing your test assembly.

Then, of course, you can always use the preprocessor to the same
effect:

#if TEST
public
#else
private
#endif
void myMethod(int param1) { ... }

and then define or not define TEST for your configurations as needed.

The first method seems much better to me than the second, because
unit tests should be done on the same binaries that are to be
delivered.

Arne

 

[Arne Vajhøj]

2) A modifier for marking a method as test visible, but hidden
otherwise. It might shut off when in release mode or something.

private testable void myMethod(int param1) { ... }

That type of functionality is often requested.

But in most cases I think it is a misunderstanding.

Unit tests are supposed to test whether the implementation
fulfill the exposed contract.

They really should only test public methods.

If the implementation is changed including removing and
adding private methods, then the unit tests should
not need to be changed.

Arne

 

[Ben Voigt [C++ MVP]]

That type of functionality is often requested.

But in most cases I think it is a misunderstanding.

Unit tests are supposed to test whether the implementation
fulfill the exposed contract.

They really should only test public methods.

If the implementation is changed including removing and
adding private methods, then the unit tests should
not need to be changed.

Not for black box testing. But white box tests might need to change.

 

[Arne Vajhøj]

Not for black box testing. But white box tests might need to change.

In unit test context white box test means testing for all critical of
which some may depend on the implementation.

That can be very relevant, but it does not require exposing
non-public stuff.

Arne

 

[Ben Voigt [C++ MVP]]

In unit test context white box test means testing for all critical of
which some may depend on the implementation.

That can be very relevant, but it does not require exposing
non-public stuff.

Arne

In my understanding, the definition of the difference between white box and
black box testing is that white box tests are written with awareness of, and
ability to reach into, implementation details, while black box tests are not
(based only on the contract).

I guess there might be a distinction for "black box + code" tests where the
test is written based on the implementation details but cannot touch them at
runtime. But that tends to happen anyway as regression tests are written to
exercise specific cases which exposed former bugs.


__________ Information from ESET NOD32 Antivirus, version of virus signature database 4237 (20090712) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com