I'm revisiting this old bug to see if anything has changed and to try to
resolve it one way or the other for the final NUnit 2.x release. At the
same time, I'll answer the last (very old) post, which I seem to have
missed when it appeared.
Recapping the bug status: VB generates code to call the overloaded
Assert.That<T>(ref T actual, ...) methods whenever the first argument is
a property. I have verified that this happens in all cases of a property
argument. When the setter is private, the VB compiler generates an
error. In fact, as you will see below, VB seems to use the ref overloads
on other occasions as well.
Workarounds:
1. Put the actual value into a temporary
2. Putting the argument in parentheses, i.e. (arg.BrokenProp)
Surprisingly, both of these workarounds still call the ref T overloads,
but the compiler error is avoided and the test succeeds.
Chad asks why we need the ref T overloads. They exist for use with the
DelayedConstraint, invoked by using the .After. syntax. For example:
Assert.That(ref flag, Is.True.After(3).Seconds)
I see three ways to resolve this:
1. Just document the problem and workarounds. That's what I'll do if
there is no further response here.
2. Use a separate method for the ref calls. For example,
Assert.ByRef(flag, Is.True.After(3).Seconds)
The name might be something different, of course. I don't like this much,
since it's a breaking change
and will impact C# developers as well as VB developers. If we did it, we
would wait until NUnit 3.0 in any case.
3. Provide a separate method for VB folks who are encountering this problem.
For example:
Assert.ByVal(obj.BrokenProp, Is.EqualTo(string.Empty))
This is my favorite, if we fix it at all, since it only affects those
suffering the problem.
Comments and other suggestions are welcome.
Charlie
** Changed in: nunitv2
Status: Confirmed => Triaged
** Changed in: nunitv2
Assignee: (unassigned) => Charlie Poole (charlie.poole)
** Changed in: nunitv2
Milestone: None => 2.6.0rc
** Also affects: nunit-3.0
Importance: Undecided
Status: New
** Changed in: nunit-3.0
Status: New => Triaged
** Changed in: nunit-3.0
Importance: Undecided => Low
** Changed in: nunit-3.0
Assignee: (unassigned) => Charlie Poole (charlie.poole)
** Changed in: nunit-3.0
Milestone: None => 2.9.6
--
You received this bug notification because you are a member of NUnit
Developers, which is subscribed to NUnit V2.
https://bugs.launchpad.net/bugs/498690
Title:
Assert.That() doesn't like properties with scoped setters
Status in NUnit Test Framework:
Triaged
Status in NUnit V2 Test Framework:
Triaged
Bug description:
Public Class SomeClass
Public Property BrokenProp() As String
Get
Return String.Empty
End Get
Private Set(ByVal value As String)
End Set
End Property
End Class
<TestFixture()> Public Class clsTestTask
<Test()> Public Sub TestXyz()
Dim obj As New SomeClass()
Expect(obj.BrokenProp, EqualTo(String.Empty))
End Sub
End Class
The above code produces a compiler error:
Error 1 'Set' accessor of property 'BrokenProp' is not accessible.
If the scoping wasn't applied to the setter on the property or the property
was ReadOnly, the compile error goes away.
This is a .NET 2.0 assembly, compiled with the Visual Studio 2008 SP1.
NUnit 2.4.7 and prior did not experience this issue.
BTW, I've also started a Google Group posting for this issue:
http://groups.google.com/group/nunit-discuss/browse_thread/thread/edb56db3d3e60195
[From SF:2792355]
SF Comment:
More info... the equivalent scoped setter in C# does not have this problem.
It arises solely with VB.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nunit-3.0/+bug/498690/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~nunit-core
Post to : nunit-core@lists.launchpad.net
Unsubscribe : https://launchpad.net/~nunit-core
More help : https://help.launchpad.net/ListHelp
