you don't use that variable in your method body so i guess null would be as fine as anything else

User interface testing is a thorny subject to say the least. If you really want real in depth testing of your user interface then my advice to you is to head for model view controller pattern. That pattern's main goal is the separation of concerns between the three entities that give it its name. More generally speaking you don't need a method to return some value in order to unit test it. One possible way of asserting a result in your case would be to make a simple unit test that says if input key char is 13 then make sure that after the txtDate_KeyPress is called the txtMiles has focus. then another unit test would asset that if the key char is between this and that, e.handled is true. or false. the way you have it set up: [Test Method] public void txtDate_KeyPressTest() { frmMileage_Accessor target = new frmMileage_Accessor(); // TODO: Initialize to an appropriate value object sender = null; // TODO: Initialize to an appropriate value KeyPressEventArgs e = null; // TODO: Initialize to an appropriate value target.txtDate_KeyPress(sender, e); } i would do something like this: [Test Method] public void txtDate_KeyPressTest_Enter() { //Arrange frmMileage_Accessor target = new frmMileage_Accessor(); object sender = null; // Does not matter since you're not using this parameter KeyPressEventArgs args = new KeyPressEventArgs((char)13); //Act target.txtDate_KeyPress(sender, args); //Assert Assert.IsTrue(target.txtMiles.Focused); } [Test Method] public void txtDate_KeyPressTest_Number() { //Arrange frmMileage_Accessor target = new frmMileage_Accessor(); object sender = null; // Does not matter since you're not using this parameter KeyPressEventArgs args = new KeyPressEventArgs((char)50); //Act target.txtDate_KeyPress(sender, args); //Assert Assert.IsFalse(args.Handled); } ... etc. also, consider using Char.IsDigit(e.KeyChar) instead of e.KeyChar >= '0' && e.KeyChar <= '9'. it's a bit more clear Regards

How to Test Private and Protected methods in .NET[^]

Hey, That usually occurs when using Response.Redirect("url"). Find the place where you do this and use Response.Redirect("url", false); By default response.redirect will end the response thread and when you specify false you instruct it not to. I don't really know why you would want that. Regards