How can I make my unit tests fail if I add something to my code?

I want my unit tests to cover my POCOs.

How can I check them?

What if I add a new property? How do I run my test?

Testing properties and methods that I know, but the problem is how to make sure my tests fail, something is added to my poco's.

0


a source to share


5 answers


From reading your question, you either misunderstand what POCO is or you misunderstand unit testing.

POCO is just an old fashioned object. It has state and behavior. You unit test the state by injecting (setting) values ​​into properties and claiming that this is the value you expected. You unit test the behavior by asserting expectations against methods.

Here is a simplified example of POCO and its tests. Note that there is more test code than implementation code. When unit testing is done correctly (TDD), it is.



public class Person
{
    private Name name = Name.Empty;
    private Address address = Address.Empty;
    private bool canMove;

    public Name Name
    {
        set { name = value; }
        get { return name; }
    }

    public Address Address
    {
        private set { address = value; }
        get { return address; }
    }

    public bool CanMove
    {
        set { canMove = value; }
        get { return value; }
    }

    public bool MoveToNewAddress(Address newAddress)
    {
        if (!CanMove) return false;
        address = newAddress;
        return true;
    }
}

[TestFixture]
public class PersonTests
{
    private Person toTest;
    private readonly static Name NAME = new Name { First = "Charlie", Last = "Brown" };
    private readonly static Address ADDRESS =
        new Address {
            Line1 = "1600 Pennsylvania Ave NW",
            City = "Washington",
            State = "DC",
            ZipCode = "20500" };

    [SetUp]
    public void SetUp()
    {
        toTest = new Person;
    }

    [Test]
    public void NameDefaultsToEmpty()
    {
        Assert.AreEqual(Name.Empty, toTest.Name);
    }

    [Test]
    public void CanMoveDefaultsToTrue()
    {
        Assert.AreEqual(true, toTest.CanMove);
    }

    [Test]
    public void AddressDefaultsToEmpty()
    {
        Assert.AreEqual(Address.Empty, toTest.Address);
    }

    [Test]
    public void NameIsSet()
    {

        toTest.Name = NAME;
        Assert.AreEqual(NAME, toTest.Name);
    }

    [Test]
    public void CanMoveIsSet()
    {
        toTest.CanMove = false;
        Assert.AreEqual(false, toTest.CanMove);
    }

    [Test]
    public void AddressIsChanged()
    {
        Assert.IsTrue(toTest.MoveToNewAddress(ADDRESS));
        Assert.AreEqual(ADDRESS, toTest.Address);
    }

    [Test]
    public void AddressIsNotChanged()
    {
        toTest.CanMove = false;
        Assert.IsFalse(toTest.MoveToNewAddress(ADDRESS));
        Assert.AreNotEqual(ADDRESS, toTest.Address);
    }
}

      

To make the test fail first, close the methods or properties, but do not execute any behavior. Run your tests, watch them fail, then add the behavior one line at a time until it passes. Stop as soon as it passes. Don't write more code if you don't write more tests (unless you refactor, in which case you don't add behavior).

+3


a source


Testing is a test of whether what is written can do what it is supposed to do, nothing more, nothing more. So if you are writing some code, you are doing it for a reason. Your tests should reflect that the code actually matches the reason you wrote the code. What is this, there is nothing else. Iow: If you're writing a bunch of classes, you should check if the behavior you wrote is valid versus what the behavior is supposed to do.



+4


a source


If you want to add a new function to the class, write a test that fails because the function was not implemented, then implement that function and watch the test pass.

Or...

Run code coverage metrics as part of the build. They will indicate if a code-gas not covered by testing has been added.

Or...

Run mutation tests as part of the build. They will indicate if any tests that cover the code pass and not test anything.

Or all of the above.

+1


a source


  • I believe you shouldn't be testing frameworks along with your own code for example if you have an auto-generated property:

    public string Name
    {get;set;}
    
          

    there is no need to have a test method to make sure it works fine.

  • You shouldn't be checking the internal state of your class, you should be checking its behavior instead.
  • Sometimes (some might say always), it's best to write a test before writing the code. So you have to understand what you want instead of how to do it. (This approach is called test-driven development)

Here's the TDD loop:

  • Record the test and get a red signal
  • Enter the code and get a green signal
  • Refactor your code and you should get a green signal
+1


a source


Perhaps by POCOs you meant DTO, in which case the answer would be:

No, you shouldn't be testing your DTOs - rather, check the services that work with them.

+1


a source







All Articles