OT - Things I want in VS and C#

  • Thread starter Thread starter jehugaleahsa
  • Start date Start date
J

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.
 
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.
Click to expand...

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) { ... }
Click to expand...

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.
 
Pavel said:
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) { ... }
Click to expand...

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.
Click to expand...

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
 
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) { ... }
Click to expand...

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
 
Arne said:
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.
Click to expand...

Not for black box testing. But white box tests might need to change.
 
Ben said:
Not for black box testing. But white box tests might need to change.
Click to expand...

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
 
Arne Vajhøj said:
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
Click to expand...

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
 
Back
Top