Skip to main content ホーム クリエイター rudironsoni synaxis dotnet-testing-private-internal-testing
dotnet-testing-private-internal-testing Guide for Private and Internal member testing strategies. Use when you need to test private or internal members, configure InternalsVisibleTo, or evaluate testability design. Covers design-first thinking, reflection testing, strategy pattern refactoring, AbstractLogger pattern, and decision frameworks.
Keywords: private method testing, internal testing, InternalsVisibleTo, reflection testing, GetMethod BindingFlags, Meziantou.MSBuild.InternalsVisibleTo, testability design, strategy pattern refactoring, testability
インストールへ移動 Skills Marketplace コミュニティが作成したAIスキルを発見・探索
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/rudironsoni/Synaxis --skill dotnet-testing-private-internal-testingコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか?SkillsMP が現在取得できるファイルをダウンロードできます。
Zipをダウンロード ダウンロード中... このリポジトリの他の Skills AI-powered wiki generation for code repositories with commands, agents, and skills
Routes .NET/C# work to domain skills. Loads coding-standards for code paths.
dotnet-agent-harness-manifest Skill manifest management for dotnet-agent-harness. Tracks skill dependencies, conflicts, version compatibility, and provides validation and resolution tools. Triggers on: skill manifest, dependency resolution, skill compatibility, version conflicts, build manifest, validate dependencies.
name dotnet-testing-private-internal-testing category testing subcategory specialized description Guide for Private and Internal member testing strategies. Use when you need to test private or internal members, configure InternalsVisibleTo, or evaluate testability design. Covers design-first thinking, reflection testing, strategy pattern refactoring, AbstractLogger pattern, and decision frameworks.
Keywords: private method testing, internal testing, InternalsVisibleTo, reflection testing, GetMethod BindingFlags, Meziantou.MSBuild.InternalsVisibleTo, testability design, strategy pattern refactoring, testability
targets ["*"] license MIT metadata {"author":"Kevin Tseng","version":"1.0.0","tags":"private-testing, internal-testing, InternalsVisibleTo, reflection, testability, design","related_skills":"nsubstitute-mocking, unit-test-fundamentals, test-naming-conventions"} claudecode {} opencode {} codexcli {"short-description":".NET skill guidance for dotnet-testing-private-internal-testing"} copilot {} geminicli {} antigravity {}
Source: kevintsengtw/dotnet-testing-agent-skills (MIT). Ported into dotnet-agent-harness.
Private and Internal Member Testing Strategy Guide
This skill helps you properly handle testing of private and internal members in .NET testing, emphasizing design-first
testing thinking.
Applicable Scenarios
Use this skill when asked to perform the following tasks:
Test private or internal methods and properties
Configure InternalsVisibleTo to access internal members
Evaluate whether to test private methods or refactor design
Use Reflection to access private members
Improve code testability design
Core Principles: Design-First Thinking
Golden Rule
Good design naturally has good testability. If you find yourself frequently needing to test private methods, the design is likely problematic
Signs of Design Problems
When you want to test private methods, first check for these signs:
❌ Private methods over 10 lines with complex logic
❌ Private methods contain important business rules
❌ Private methods difficult to test indirectly through public methods
❌ Class has multiple responsibilities
Solution: Refactor Rather Than Test
public class OrderProcessor
{
public OrderResult ProcessOrder (Order order )
{
var discount = CalculateDiscount(order);
var tax = CalculateTax(order, discount);
}
private decimal CalculateDiscount (Order order ) { }
private decimal CalculateTax (Order order, discount ) { }
}
{
IDiscountCalculator _discountCalculator;
ITaxCalculator _taxCalculator;
{
_discountCalculator = discountCalculator;
_taxCalculator = taxCalculator;
}
{
discount = _discountCalculator.Calculate(order);
tax = _taxCalculator.Calculate(order, discount);
}
}
:
{
{
}
}
```text
- ✅ Framework
- ✅
- ✅ -
- ✅ -
###
- ❌ ( )
- ❌
- ❌
### 1:
, :
```
;
[ ]
[ ]
```text
- Simple direct
- No additional packages needed
- Requires hardcoded assembly names
- For signed assemblies, need to include key
Configure via MSBuild properties:
```xml
<!-- YourProject.csproj -->
<Project Sdk= >
<PropertyGroup>
<TargetFramework>net9 </TargetFramework>
</PropertyGroup>
<ItemGroup>
<AssemblyAttribute Include= >
<_Parameter1>$(AssemblyName).Tests</_Parameter1>
</AssemblyAttribute>
</ItemGroup>
</Project>
```text
- Can use MSBuild variables
- Centralized management
For complex projects, recommend NuGet package:
```xml
<!-- YourProject.csproj -->
<ItemGroup>
<PackageReference Include= Version= >
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
</PackageReference>
</ItemGroup>
<ItemGroup>
<InternalsVisibleTo Include= />
<InternalsVisibleTo Include= />
<InternalsVisibleTo Include= Key= />
</ItemGroup>
```text
- Automatically handles keys signed assemblies
-
{
{
basePrice = product.BasePrice;
discount = CalculateDiscount(customer, product);
tax = CalculateTax(product, customer.Location);
basePrice - discount + tax;
}
{
}
{
}
}
```text
```csharp
{
;
}
{
;
}
:
{
{
(customer.IsVIP)
product.BasePrice * m;
;
}
}
:
{
{
product.BasePrice * m;
}
}
{
IDiscountStrategy _discountStrategy;
ITaxStrategy _taxStrategy;
{
_discountStrategy = discountStrategy;
_taxStrategy = taxStrategy;
}
{
basePrice = product.BasePrice;
discount = _discountStrategy.Calculate(customer, product);
tax = _taxStrategy.Calculate(product, customer.Location);
basePrice - discount + tax;
}
}
```text
- Each strategy can be tested independently
- Follows Open/Closed Principle
- Easy to extend strategies
- Reduces dependency reflection
Sometimes need to mock behavior of a :
```
{
{
validated = ValidateInput(input);
(!validated)
ProcessResult.InvalidInput();
data = TransformData(input);
saved = SaveData(data);
saved
? ProcessResult.Success()
: ProcessResult.Failed();
}
{
;
}
=> ! .IsNullOrEmpty(input);
=> input.ToUpper();
}
:
{
{
;
}
}
[ ]
{
processor = TestableDataProcessor();
result = processor.Process( );
result.Success.Should().BeTrue();
}
```text
- Are methods too complex? (> lines)
- Does the ?
- ?
###
- ( , )
-
#### 2:
### : ?
- ?
- ?
- ?
### : ( )
- ,
-
#### 3:
### : ?
:
- ✅
- ✅
- ✅ -
### : ( )
- ,
- , ,
###
| | | |
| :-------------------------- | :----------------------- | :--------------------- |
| (< 10 ) | | |
| (> 10 ) | | |
| | | |
| | | - |
| - | | |
| | | |
## -
1. ** **
- ✅
- ✅
- ✅
- ✅
2. ** **
- ✅
- ✅
- ✅
3. ** **
- ✅
- ✅
- ✅
4. ** **
- ✅
- ✅
- ✅
## ' -
1. ** ' - **
- ❌
- ❌ ' /
- ❌
2. ** ' **
- ❌ '
- ❌ '
- ❌ '
3. ** ' **
- ❌
- ❌ '
- ❌
4. ** ' **
- ❌ '
- ❌
- ❌ '
##
` /` :
- ` - - - ` -
- ` - - ` -
- ` - - ` -
##
###
" ' - 30 " :
- ** 09 - : **
- : :
- : :
###
- [ ' - ]( :
###
- ` - - ` -
- ` - ` -
##
, :
- [ ]
- [ ]
- [ ]
- [ ]
- [ ] ( ., )
- [ ]
- [ ] '
- [ ]
- [ ]
- [ ]
decimal
public
class
OrderProcessor
private
readonly
private
readonly
public OrderProcessor (
IDiscountCalculator discountCalculator,
ITaxCalculator taxCalculator )
public OrderResult ProcessOrder (Order order )
var
var
public
class
DiscountCalculator
IDiscountCalculator
public decimal Calculate (Order order )
## Internal Member Testing Strategy
### When to Test Internal Members
### Appropriate Scenarios
or
class
library
development
Complex
internal
algorithm
validation
Performance
critical
internal
components
Security
related
internal
logic
Inappropriate
Scenarios
Application
layer
business
logic
should
be
public
Simple
helper
methods
Logic
that
can
be
tested
indirectly
through
public
API
Method
Using
InternalsVisibleTo
Attribute
Most
direct
method
suitable
for
simple
cases
csharp
using
System.Runtime.CompilerServices
assembly: InternalsVisibleTo("YourProject.Tests" )
assembly: InternalsVisibleTo("YourProject.IntegrationTests" )
### Pros
and
### Cons
public
### Method 2: Configuring in csproj
"Microsoft.NET.Sdk"
.0
"System.Runtime.CompilerServices.InternalsVisibleToAttribute"
### Pros: (continued)
### Method 3: Using Meziantou.MSBuild.InternalsVisibleTo (Recommended)
using
this
"Meziantou.MSBuild.InternalsVisibleTo"
"1.0.2"
"$(AssemblyName).Tests"
"$(AssemblyName).IntegrationTests"
"DynamicProxyGenAssembly2"
"0024000004800000940000000602000000240000525341310004000001000100c547cac37abd99c8db225ef2f6c8a3602f3b3606cc9891605d02baa56104f4cfc0734aa39b93bf7852f7d9266654753cc297e7d2edfe0bac1cdcf9f717241550e0a7b191195b7667bb4f64bcb8e2121380fd1d9d46ad2d92d2d15605093924cceaf74c4861eff62abf69b9291ed0a340e113be11e6a7d3113e92484cf7045cc7"
### Pros: (continued)
public
for
Supports DynamicProxyGenAssembly2 (NSubstitute/Moq )
- High readability
### Reference Resources
- [Declaring InternalsVisibleTo in the csproj - Meziantou's blog](https://www.meziantou.net/declaring-internalsvisibleto-in -the-csproj.htm )
- [GitHub - meziantou/Meziantou.MSBuild.InternalsVisibleTo](https://github.com/meziantou/Meziantou.MSBuild.InternalsVisibleTo )
### Internal Testing Risk Assessment
| Assessment Aspect | Risk Level | Description |
| :---------------- | :--------- | :--------------------------------------- |
| Encapsulation Break | Medium | Increases test dependency on internal implementation |
| Refactoring Resistance | High | Changing internal members affects tests |
| Maintenance Cost | Medium | Need to maintain both production and test code |
| Design Quality | Low | If overused, may indicate design problems |
## Private Method Testing Techniques
Covers decision tree (whether to test private methods ), reflection testing of private instance and static methods, `ReflectionTestHelper` helper class encapsulation, and risks and best practices of reflection testing.
> For complete code examples and technical details, see [references/private -method-testing.md](references/private -method-testing.md )
## Test-Friendly Design Patterns
### Strategy Pattern to Improve Testability
Refactor complex private logic into strategy pattern:
#### Before Refactoring: Hard to Test Design
```csharp
public class PricingService
public decimal CalculatePrice (Product product, Customer customer )
var
var
var
return
private decimal CalculateDiscount (Customer customer, Product product )
private decimal CalculateTax (Product product, Location location )
#### After Refactoring: Using Strategy Pattern
public
interface
IDiscountStrategy
decimal Calculate (Customer customer, Product product )
public
interface
ITaxStrategy
decimal Calculate (Product product, Location location )
public
class
StandardDiscountStrategy
IDiscountStrategy
public decimal Calculate (Customer customer, Product product )
if
return
0.1
return
0
public
class
TaiwanTaxStrategy
ITaxStrategy
public decimal Calculate (Product product, Location location )
return
0.05
public
class
PricingService
private
readonly
private
readonly
public PricingService (
IDiscountStrategy discountStrategy,
ITaxStrategy taxStrategy )
public decimal CalculatePrice (Product product, Customer customer )
var
var
var
return
### Pros: (continued)
new
on
### Partial Mock
partial
class
csharp
public
class
DataProcessor
public ProcessResult Process (string input )
var
if
return
var
var
return
protected virtual bool SaveData (string data )
return
true
private bool ValidateInput (string input )
string
private string TransformData (string input )
public
class
TestableDataProcessor
DataProcessor
protected override bool SaveData (string data )
return
true
Fact
public void Process_Using_Partial_Mock_Should_Process_Successfully ()
var
new
var
"test"
## Practical Decision Framework
### Three-Level Risk Assessment
#### Level 1: Design Quality Assessment
### Question: Is this a design problem or a testing problem?
private
10
class
have
multiple
responsibilities
Can
it
be
extracted
as
an
independent
class
Recommended
Action
Prioritize
refactoring
extract
class
strategy
pattern
Improve
testability
through
improved
design
Level
Maintenance
Cost
Assessment
Question
Will
testing
become
a
hindrance
to
refactoring
Does
the
test
depend
on
implementation
details
Will
the
test
need
significant
modification
when
refactoring
Is
it
difficult
to
locate
problems
when
tests
fail
Recommended
Action
continued
If
maintenance
cost
is
high
reconsider
testing
strategy
Consider
integration
testing
through
public
API
Level
Value
Output
Assessment
Question
Does
the
test
value
exceed
the
cost
Assess
test
value
Can
catch
real
business
logic
errors
Provides
clear
failure
messages
Runs
stably
long
term
at
reasonable
cost
Recommended
Action
continued
If
value
is
insufficient
look
for
alternative
testing
strategies
Consider
performance
testing
integration
testing
or
other
approaches
Decision
Matrix
Scenario
Recommended
Approach
Reason
Simple
private
methods
lines
Test
through
public
methods
Low
maintenance
cost
Complex
private
logic
lines
Refactor
to
independent
class
Improve
design
and
testability
Framework
internal
algorithms
Use
InternalsVisibleTo
Need
precise
internal
behavior
testing
Legacy
system
private
methods
Consider
reflection
testing
Difficult
to
refactor
short
term
Security
related
private
logic
Refactor
or
use
reflection
testing
Need
independent
correctness
verification
Frequently
changing
implementation
details
Avoid
direct
testing
Tests
become
fragile
DO
Recommended
Practices
Design
First
Prioritize
refactoring
over
testing
private
methods
Use
dependency
injection
and
interface
abstraction
Apply
strategy
pattern
to
separate
complex
logic
Maintain
single
responsibility
principle
Test
Public
Behavior
Focus
on
testing
public
API
behavior
Test
private
logic
indirectly
through
public
methods
Use
integration
testing
to
cover
complex
flows
Use
InternalsVisibleTo
Wisely
Only
for
framework
or
class
library
development
Use
Meziantou.MSBuild.InternalsVisibleTo
to
simplify
configuration
Document
why
internal
visibility
is
needed
Use
Reflection
Cautiously
Create
helper
methods
to
encapsulate
reflection
logic
Mark
in
test
names
that
reflection
is
used
Regularly
review
whether
refactoring
is
possible
DON
T
Practices
to
Avoid
Don
t
Over
Test
Private
Methods
Avoid
writing
tests
for
every
private
method
Don
t
test
simple
getters
setters
Avoid
testing
pure
delegation
calls
Don
t
Ignore
Design
Problems
Don
t
use
testing
as
an
alternative
to
design
problems
Don
t
break
encapsulation
for
testing
Don
t
let
tests
hinder
refactoring
Don
t
Depend
on
Implementation
Details
Avoid
testing
call
order
of
private
methods
Don
t
validate
values
of
private
fields
Avoid
testing
frequently
changing
implementation
details
Don
t
Abuse
InternalsVisibleTo
Don
t
open
internal
for
application
layer
code
Avoid
excessive
test
project
visibility
Don
t
use
it
to
replace
proper
public
API
Example
Reference
See
templates
directory
for
complete
examples
internals
visible
to
examples.cs
InternalsVisibleTo
configuration
examples
reflection
testing
examples.cs
Reflection
testing
technique
examples
strategy
pattern
refactoring.cs
Strategy
pattern
refactoring
examples
Reference
Resources
Original
Articles
This
skill
content
is
distilled
from
the
Old
School
Software
Engineer
s
Testing
Practice
Day
Challenge
article
series
Day
Testing
Private
and
Internal
Members
Private
and
Internal
Testing
Strategies
Article
https
Sample
Code
https
Official
Documentation
Meziantou
s
Blog
InternalsVisibleTo
https
Related
Skills
unit
test
fundamentals
Unit
testing
basics
nsubstitute
mocking
Test
doubles
and
mocking
Testing
Checklist
When
handling
private
and
internal
member
testing
confirm
the
following
checklist
items
Evaluated
whether
to
refactor
rather
than
test
private
methods
Internal
members
really
need
to
be
open
to
test
projects
Using
appropriate
InternalsVisibleTo
configuration
method
Reflection
tests
use
helper
methods
for
encapsulation
Test
names
clearly
indicate
test
type
e.g
using
reflection
Strategy
pattern
and
other
design
patterns
considered
for
complex
logic
Tests
won
t
become
a
hindrance
to
refactoring
Test
value
exceeds
maintenance
cost
Not
overly
dependent
on
implementation
details
Regularly
review
appropriateness
of
testing
strategy