To be honest, I struggle with the whole concept. I'm now working on (for me) a very large and complex system with thousands of unit tests ... and yet I'm unaware of any instance of a unit test ever failing for any reason other than because the developer changed the unit under test without changing the unit test.

One of the reasons for writing unit tests is to protect you from your future self

While you may never have seen one of these tests failing (on a build pipeline for example) what you have probably not seen is how often they fail on individual developer machines as that person is refactoring.

I deal with a complex system with good unit test coverage and I have regularly refactored some code to find that my tests fail locally before I commit - telling me that I've not entirely understood what the code was doing before I changed it.

When you initially write the code, you (hopefully) have an in depth understanding of what the code is doing.

When you return to this code in six months time, this understanding will have diminished and you may no longer have a full understanding of some of the edge cases.

If you write the unit tests to validate what the intended behaviour of the code was and have covered as many edge cases as you reasonably can, then hopefully 'future you' can rely on these when making changes.

I have found using something like [Bddfy][1] to provide a structure to the unit tests in a way that describes a feature/scenario to be very useful, e.g.

[Fact]
public void CardHasBeenDisabled()
{
    this.Given(s => s.GivenTheCardIsDisabled())
        .When(s => s.WhenTheAccountHolderRequests(20))
        .Then(s => s.CardIsRetained(true), "Then the ATM should retain the card")
            .And(s => s.AndTheAtmShouldSayTheCardHasBeenRetained())
        .BDDfy(htmlReportName: "ATM");
}

And allows you to align how the unit tests are written with the language in your feature tickets.

To be honest, I struggle with the whole concept. I'm now working on (for me) a very large and complex system with thousands of unit tests ... and yet I'm unaware of any instance of a unit test ever failing for any reason other than because the developer changed the unit under test without changing the unit test.

One of the reasons for writing unit tests is to protect you from your future self

While you may never have seen one of these tests failing (on a build pipeline for example) what you have probably not seen is how often they fail on individual developer machines as that person is refactoring.

I deal with a complex system with good unit test coverage and I have regularly refactored some code to find that my tests fail locally before I commit - telling me that I've not entirely understood what the code was doing before I changed it.

When you initially write the code, you (hopefully) have an in depth understanding of what the code is doing.

When you return to this code in six months time, this understanding will have diminished and you may no longer have a full understanding of some of the edge cases.

If you write the unit tests to validate what the intended behaviour of the code was and have covered as many edge cases as you reasonably can, then hopefully 'future you' can rely on these when making changes.

I have found using something like Bddfy to provide a structure to the unit tests in a way that describes a feature/scenario to be very useful, e.g.

[Fact]
public void CardHasBeenDisabled()
{
    this.Given(s => s.GivenTheCardIsDisabled())
        .When(s => s.WhenTheAccountHolderRequests(20))
        .Then(s => s.CardIsRetained(true), "Then the ATM should retain the card")
            .And(s => s.AndTheAtmShouldSayTheCardHasBeenRetained())
        .BDDfy(htmlReportName: "ATM");
}

And allows you to align how the unit tests are written with the language in your feature tickets.

To be honest, I struggle with the whole concept. I'm now working on (for me) a very large and complex system with thousands of unit tests ... and yet I'm unaware of any instance of a unit test ever failing for any reason other than because the developer changed the unit under test without changing the unit test.

While you may never have seen one of these tests failing (on a build pipeline for example) what you have probably not seen is how often they fail on individual developer machines as that person is refactoring.

I deal with a complex system with good unit test coverage and I have regularly refactored some code to find that my tests fail locally before I commit - telling me that I've not entirely understood what the code was doing before I changed it.

When you initially write the code, you (hopefully) have an in depth understanding of what it is the code is doing.

When you return to this code in six months time, this understanding will have diminished and you may no longer have a full understanding of some of the edge cases.

If you write the unit tests to form the basis of what the intended behaviour of the code should do and have covered as many edge cases as you reasonably can, then hopefully 'future you' can rely on these when making changes.

I have found using something like [Bddfy][1] to provide a structure to the unit tests in a way that describes a feature/scenario to be very useful, e.g.

[Fact]
public void CardHasBeenDisabled()
{
    this.Given(s => s.GivenTheCardIsDisabled())
        .When(s => s.WhenTheAccountHolderRequests(20))
        .Then(s => s.CardIsRetained(true), "Then the ATM should retain the card")
            .And(s => s.AndTheAtmShouldSayTheCardHasBeenRetained())
        .BDDfy(htmlReportName: "ATM");
}

To be honest, I struggle with the whole concept. I'm now working on (for me) a very large and complex system with thousands of unit tests ... and yet I'm unaware of any instance of a unit test ever failing for any reason other than because the developer changed the unit under test without changing the unit test.

One of the reasons for writing unit tests is to protect you from your future self

While you may never have seen one of these tests failing (on a build pipeline for example) what you have probably not seen is how often they fail on individual developer machines as that person is refactoring.

I deal with a complex system with good unit test coverage and I have regularly refactored some code to find that my tests fail locally before I commit - telling me that I've not entirely understood what the code was doing before I changed it.

When you initially write the code, you (hopefully) have an in depth understanding of what the code is doing.

When you return to this code in six months time, this understanding will have diminished and you may no longer have a full understanding of some of the edge cases.

If you write the unit tests to validate what the intended behaviour of the code was and have covered as many edge cases as you reasonably can, then hopefully 'future you' can rely on these when making changes.

I have found using something like [Bddfy][1] to provide a structure to the unit tests in a way that describes a feature/scenario to be very useful, e.g.

[Fact]
public void CardHasBeenDisabled()
{
    this.Given(s => s.GivenTheCardIsDisabled())
        .When(s => s.WhenTheAccountHolderRequests(20))
        .Then(s => s.CardIsRetained(true), "Then the ATM should retain the card")
            .And(s => s.AndTheAtmShouldSayTheCardHasBeenRetained())
        .BDDfy(htmlReportName: "ATM");
}

And allows you to align how the unit tests are written with the language in your feature tickets.