Unit Testing VB.NET Code

Analogy categoryAnalogies

Choosing a Test Framework for VB.NET

VB.NET code can be unit tested with any of the three major .NET test frameworks -- MSTest, NUnit, or xUnit -- because all three are ordinary NuGet packages built on the CLR, with no VB-specific restrictions. MSTest, Microsoft's own framework, integrates most tightly with Visual Studio's Test Explorer out of the box and uses <TestClass> and <TestMethod> attributes; NUnit uses <TestFixture> and <Test> and has a longer history with more advanced assertion syntax like constraint-based Assert.That; xUnit favors convention over attributes (a public class is implicitly a fixture, and [Fact] marks a test method) and deliberately drops [SetUp] in favor of constructor-based initialization. Whichever framework you pick, the VB.NET test project template in Visual Studio wires up the correct references automatically.

🏏

Cricket analogy: Choosing MSTest, NUnit, or xUnit is like choosing which domestic T20 league to train in -- IPL, Big Bash, or The Hundred -- each has its own rules and format quirks, but the underlying cricket skills (batting, bowling) transfer across all of them.

Writing a Basic Test Class

A unit test in VB.NET follows the same Arrange-Act-Assert structure used in every .NET language: you set up input values and dependencies (Arrange), invoke the method under test (Act), and verify the outcome with an assertion method like Assert.AreEqual or Assert.IsTrue (Assert). VB.NET's attribute syntax uses angle brackets, so a test class is decorated <TestClass()> and a test method <TestMethod()> in MSTest, which is functionally identical to C#'s [TestClass] and [TestMethod] but visually distinct because of VB.NET's attribute bracket syntax. Test method names should describe the scenario and expected outcome clearly, such as CalculateDiscount_WhenQuantityExceedsTen_AppliesTenPercentOff, so a failing test's name alone communicates what broke.

🏏

Cricket analogy: Arrange-Act-Assert mirrors a bowler's pre-delivery routine: mark the run-up (Arrange), bowl the delivery (Act), and check with the umpire whether it's out or not (Assert), each phase has a distinct, well-defined job.

vbnet

Imports Microsoft.VisualStudio.TestTools.UnitTesting

<TestClass()>
Public Class DiscountCalculatorTests

    <TestMethod()>
    Public Sub CalculateDiscount_WhenQuantityExceedsTen_AppliesTenPercentOff()
        ' Arrange
        Dim calculator As New DiscountCalculator()
        Dim quantity As Integer = 12
        Dim unitPrice As Decimal = 50D

        ' Act
        Dim result As Decimal = calculator.CalculateTotal(quantity, unitPrice)

        ' Assert
        Assert.AreEqual(540D, result) ' 600 - 10% discount
    End Sub

    <TestMethod()>
    Public Sub CalculateDiscount_WhenQuantityIsZeroOrLess_ThrowsArgumentException()
        Dim calculator As New DiscountCalculator()

        Assert.ThrowsException(Of ArgumentException)(
            Sub() calculator.CalculateTotal(0, 50D))
    End Sub

End Class

Mocking Dependencies

A unit test should isolate the class under test from its real dependencies -- a database, a file system, or a web service -- so it runs fast and deterministically; this is achieved with mocking libraries like Moq, which work with VB.NET exactly as they do with C# since they operate purely through reflection over interfaces. To make a class testable, you depend on an interface (IOrderRepository) rather than a concrete class (SqlOrderRepository), inject that interface through the constructor, and in the test create a mock implementation with New Mock(Of IOrderRepository)(), configure its behavior with .Setup(...), and pass mockRepository.Object into the class under test. This lets you simulate edge cases -- a repository that throws a timeout exception, or returns an empty list -- that would be difficult or slow to reproduce against a real database.

🏏

Cricket analogy: Mocking a dependency is like a batsman practicing against a bowling machine set to simulate a specific delivery, a yorker at 140 km/h, rather than waiting for a real fast bowler to bowl that exact ball in a live match.

Moq works identically in VB.NET as in C#: Dim mockRepo As New Mock(Of IOrderRepository)() followed by mockRepo.Setup(Function(r) r.GetById(1)).Returns(New Order With {.Id = 1}) configures the fake, and mockRepo.Object is what you inject into the class under test.

Structuring Tests for Maintainability

As a VB.NET test suite grows, common setup logic (creating a database context, seeding test data) belongs in a <TestInitialize()> method (MSTest) or <SetUp> (NUnit) that runs before every test in the class, rather than being duplicated in each test method, and <TestCleanup()>/<TearDown> handles releasing resources afterward. Grouping related tests into one class per class-under-test (e.g., DiscountCalculatorTests for DiscountCalculator) keeps failures easy to trace back to the code that broke, and using data-driven tests -- MSTest's <DataTestMethod()> with <DataRow()> attributes, or NUnit's <TestCase()> -- avoids copy-pasting nearly identical test methods for each input variation.

🏏

Cricket analogy: TestInitialize running before every test is like ground staff rolling and preparing the pitch before every single day of a Test match, ensuring consistent starting conditions regardless of who's testing.

Avoid sharing mutable state between test methods (e.g., a Shared/static field modified by one test) unless it is reset in TestInitialize -- tests that pass or fail depending on execution order are a common and hard-to-diagnose source of flaky test suites.

VB.NET can be unit tested with MSTest, NUnit, or xUnit, all installed as ordinary NuGet packages with no VB-specific restrictions.
VB.NET attributes use parentheses-with-angle-bracket syntax, e.g. <TestClass()> and <TestMethod()>, functionally equivalent to C#'s [TestClass] and [TestMethod].
Tests should follow the Arrange-Act-Assert structure with descriptive method names that state the scenario and expected outcome.
Mocking libraries like Moq isolate the class under test from real dependencies by faking interfaces, enabling fast and deterministic tests.
TestInitialize/SetUp and TestCleanup/TearDown centralize repeated setup and teardown logic instead of duplicating it in every test.
Data-driven tests (DataTestMethod/DataRow in MSTest, TestCase in NUnit) avoid copy-pasted near-duplicate test methods.
Shared mutable state between tests should be avoided or reset in TestInitialize to prevent order-dependent flaky tests.