mattwhitfield / Unitverse

A unit test generation extension for Visual Studio that aims to always produce code that compiles - covering the basic cases automatically and preparing as much as it can for the complex cases.
MIT License
89 stars 20 forks source link

Add Assert for var result #229

Closed shshshshgoodnj closed 1 year ago

shshshshgoodnj commented 1 year ago

Hello, I am a user who uses Unitverse that you created.

When a variable is created for an instance in TCs, Assert.IsNotNull is created for the value of the instance variable. However, when a variable for the 'result' is generated, it exports it all to Assert.Fail(). there are too many TCs that emit 'Assert.Fail("Create or Modify")', so I'm having a hard time fixing them all.

The result value refers the return value of the method, and Assert.IsNull if the return value is null. If it's not null, I want to emit it with Assert.IsNotNull.

Below is an example of export Assert for var result and var instance.

        public void CanConstructTest()
        {
            // Act
            var instance = new NetInterface(a, b, c);

            // Assert
            Assert.IsNotNull(instance);
        } //var instance exports Assert.IsNotNull
        [TestMethod]
        public void CanCallTest()
        {
            // Arrange
            var @type = _fixture.Create<NetworkInterfaceType>();

            // Act
            var result = NetworkUtil.GetPhysicalAddress(type);

            // Assert
            Assert.Fail("Create or modify test");
        } //var result does not export Assert.IsNotNull

We would like to allow the result to be exported either Assert.IsNotNull or Assert.IsNull.

mattwhitfield commented 1 year ago

I'm not entirely sure what you mean here. Are you saying that you would just want the CanCallTest in your example to emit Assert.IsNotNull(result) rather than Assert.Fail? The problem with this is that it would mean that we were generating a passing test without being able to perform any sort of verification.

The reason we generate with Assert.Fail is because you have to add your own logic to actually verify that the result is what you wanted it to be. We don't actually inspect the code within the method to try and figure out what the assertions should be. The only inspection of that sort that we do is trying to figure out what calls are made to dependencies, so we can set up mocks...

mattwhitfield commented 1 year ago

Given this has been open for a month now, will close it - the behaviour is by design 👍