Comments (12)
I think this is up to project maintainers to decide. It is true that we do not use internals visible in core framework for reasons discussed in the linked issues. It is intentional choice made by the maintainers of the core framework.
The higher-level sub-projects in CoreFX repo are maintained by different folks, with different opinions, and they are happy to use InternalsVisibleTo, e.g.:
https://github.com/dotnet/corefx/blob/master/src/System.Reflection.Metadata/src/Properties/InternalsVisibleTo.cs
https://github.com/dotnet/corefx/blob/master/src/System.Numerics.Tensors/src/Properties/InternalsVisibleTo.cs
Number of other repos in CoreFX use InternalsVisibleTo. For example, the list of InternalsVisibleTo in Roslyn is so long that it does not even fit on a single screen.
I do not see a problem with WinForms using InternalsVisibleTo if the WinForms maintainers understand the trade-off and are happy to deal with the consequences.
from winforms.
I disagree with this, for various reasons. :)
But the most important reason is that we want our unit tests to exercise our code at the lowest level possible.
Imagine the scenario where you have a public method calling 5 internal methods. Imagine each of the internal methods has 3 code paths. That means, to get 100% code coverage, you have to write 15 unit tests for a single public function, and that's not including any other code paths in the public function.
It's much cleaner and more straightforward to test each internal method 3 times, exercising all the code paths of each one individually.
The argument that "we don't need to test internal methods" is not a good one, because the quality bar of our internal code should be the same as the bar for our public code.
Please don't remove the internals visible to, I'm very much against this.
from winforms.
Wes' argument against friend assemblies: https://github.com/dotnet/corefx/issues/1604#issuecomment-98319086 He says that we'll have to re-visit our 3 clean internal tests from Adam's example each time we touch the implementation.
On the other hand we have internal types that are exposed to windows via native APIs (AccessibleObjects associated with internal types) and thus are part of our public contract.... being able to new them up would be really sweet, compared to introducing a custom accessibility client.
@Shyam-Gupta how many existing tests in System.Windows.Forms are affected?
from winforms.
(somewhat artificially) restrict the domain of our tests
InternalsVisibleTo does not imply that you have to restrict domain of your tests.
We do have occasional tests in corefx for core framework that test internals. They use private reflection instead of InternalsVisibleTo. Private reflection has extra barrier to entry, and thus it is used only as last resort. This setup without InternalsVisibleTo strongly encourages use the public APIs for as much testing as possible. As I have said, it is up to project maintainers to choose whether it is a worthwhile trade-off.
from winforms.
I just can't understand why we wouldn't want to be able to easily test internal methods in isolation. If engineers use this as a crutch to avoid testing publics, that's a different problem to solve. They don't have to be mutually exclusive.
Looking at how many internal tests exist right now is not a fair value comparison. What you should be looking at is the opportunity cost of not doing this. How many internal methods exist in the code base that will not be tested in isolation once we remove InternalsVisisbleTo? The answer is 2688, and that's just in System.Windows.Forms.dll.
from winforms.
It's really up to your engineering team to decide this, but we do have a different policy in other dotnet repositories and you're welcome to research the background on that by reviewing those (heated) discussions in the other repositories.
from winforms.
But even if your team isn't testing internals across the board, what if I wanted to test one I just wrote and I want to make sure that test runs as part of the ci build?
I would think having the option to do so is more valuable than getting rid of that option because of a repo policy.
from winforms.
I'm not going to defend this position as it is a bit of a philosophical debate. I just wanted to point out that winforms is taking a different path than other dotnet foundation repositories.
Here are some examples:
https://github.com/dotnet/corefx/issues/1604
dotnet/corefx#29251 (comment)
@stephentoub or @jkotas might be able to state the position of CoreFx / CoreCLR better than I can. I couldn't find details in our contribution guidelines or other docs.
from winforms.
Is there any reason why we would actively prevent people from writing tests?
I understand the concern of testing internals without publics when public-facing surface area is our greatest level of concern, but I don't think anyone is suggesting that testing internals is a substitute for testing publics?
As Jan and Eric have indicated, this is really a philosophical debate about the breath of our testing and whether or not we should (somewhat artificially) restrict the domain of our tests and the ability for community members to write tests. Maybe we should have a brief meeting about this? --To discuss the trade-offs of each approach?
from winforms.
@Shyam-Gupta how many existing tests in System.Windows.Forms are affected?
@Tanya-Solyanik : ~100 tests are affected and will need to be fixed\rewritten.
from winforms.
As @jkotas stated, what the owners of the winforms project decide is up to them.
For corefx, though, I enumerated various reasons we don't like InternalsVisibleTo at dotnet/corefx#29251 (comment), and it includes actually making the binaries that we ship worse. There are some times when we want to test internals, and we do that in one of two ways:
- Dedicated unit test rather than functional test projects that include the relevant product source files. If the functionality is testable on its own, that means it can stand on its own, and so it should be fine to include the source in such projects. We do this in particular in some of our networking projects. This also makes it very explicit what is testable and what isn't.
- Private reflection as an absolute last resort: I could probably count on one hand the number of times we do this, though.
from winforms.
Discussed within the internal team today. We are not removing this and instead allowing it to be added to other binaries. Testing publics is the ciritcal, yet we should also allow testing internals. Changing the issue name to correspond with the new strategy.
from winforms.
Related Issues (20)
- Unstable unit test: System.Windows.Forms.UITests.ButtonTests.Button_CancelButton_EscapeClicksCancelButtonAsync
- Unstable unit test: System.Windows.Forms.UITests.ButtonTests.Button_Press_Enter_Fires_OnClickAsync
- Unstable unit test: System.Windows.Forms.UITests.ListViewTests.ListView_Group_NavigateKeyboard_SucceedsAsync
- Unstable unit test: System.Windows.Forms.UITests.NumericUpDownTests.NumericUpDownAccessibleObject_Focused_ReturnsCorrectValueAsync
- WinForms fails to build with a nightly SDK HOT 2
- Massive GDI (region) leak. Help needed. HOT 9
- Unresponsiveness issue during Real-Time Updates in Winforms DataGridView HOT 4
- [ARM64]The Form1.cs[Design] page cannot load successfully after installed the latest .NET 9.0 Preview4 or Preview5 HOT 3
- GDI/BitBlt features for .NET Core? HOT 1
- Add GetData<T> Method to Clipboard HOT 2
- The selected control should have a solid border in the DemoConsole application HOT 1
- Single instance app doesn't work when same app is in different folders HOT 3
- Investigate BinaryFormatter Impact On DataSets HOT 1
- Restrict Certain OLE Data Coming in From Different Processes
- Investigate JSON Serialization/Deserialization in OLE
- Allow Binary Format Binder Specification
- Shrink/ losslessly compress `ICO` resource files to reduce size of apps published with SingleFile/AOT HOT 3
- Unstable unit test: System.Windows.Forms.Tests.ToolStripTests.ToolStrip_WndProc_InvokeMouseActivateWithHandle_Success
- Anchors of user control don't work when scaling on high DPI (#6381) HOT 3
- Allow internal types to be selected as object data source for binding HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from winforms.