nunit-core team mailing list archive

[Charlie Poole <charlie@xxxxxxxxx>]

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