Odtnhj

Started programming, I am looking at some unit test naming convention: This is a popular one.
MethodName_StateUnderTest_ExpectedBehavior

https://dzone.com/articles/7-popular-unit-test-naming

If I have a Class ParseVendorSupply,

What would I name the first unit test?
FromCsv_ParseCorrectly_IsGood

What would I name the second unit test?
FromCsv_ParseCorrectly_IsIncorrect

//Electronics store 
public class ParseVendorSupply

 public VendorSupply FromCsv(string csvLine)
 
 string values = csvLine.Split(',');
 VendorSupply vendorsupply = new VendorSupply();
 vendorsupply.VendorId = Convert.ToInt16(values[0]);
 vendorsupply.ProductId = Convert.ToInt16(values[1]);
 vendorsupply.Quantity = Convert.ToInt16(values[2]);
 return vendorsupply;
 


public class ParseVendorSupplyTest


 ParseVendorSupply parseVendorSupplytest = new ParseVendorSupply();

 [Test]
 public void FromCsv_ParseCorrectly_IsGood()
 
 string csvLineTest = "5,8,3";
 VendorSupply vendorsupply = parseVendorSupplytest.FromCsv(csvLineTest);
 Assert.AreEqual(5, vendorsupply.VendorId);
 Assert.AreEqual(8, vendorsupply.ProductId);
 Assert.AreEqual(3, vendorsupply.Quantity);
 
 [Test]
 public void FromCsv_ParseCorrectly_IsIncorrect()
 
 string csvLineTest = "5,testdatatype,3,testextrawords";
 VendorSupply vendorsupply = parseVendorSupplytest.FromCsv(csvLineTest);
 Assert.AreEqual(5, vendorsupply.VendorId);

 

What you are doing is perfectly good. (I'll make one suggestion below.)

As noted, there is a lot of room for opinion here. But that leads me to this answer...

Make a convention that is clear and understandable by those who need to understand it. That's you and any teammates who work in the code. Nobody else needs to agree. But also, think about your "future self" wanting to understand as well.

Also, if you decide to change, then just do it. There is no need for consistency across files if you have made it easy to understand. So don't go back and change other files just for consistency. Don't make rules, create patterns that arise out of your own individual actions.

One point regarding the convention you have tentatively adopted. You seem to be making the second and third components be about the same thing. If that's the case, they are redundant and you shouldn't use both. Alternatively, make the second be about the condition that gives rise to the result of the third. For example

FromCsv_WhenWellFormed_ParsesCorrectly()
FromCsv_WhenBadlyFormed_GivesError()

However, if it were me, I would probably drop the third part entirely since it's obvious what the result should be when the data is well- or badly formed.

If desired, you could have more than one badly formed (or even well-formed) test, using different names. Alternatively, make the correct and incorect tests into test cases providing the data as a parameter.