I think it would be really cool if I could extend your Assert Class t oadd my own Asserts and override existing ones, but some mean person sealed the class on me!
I want to do something like this:
public class AutomationAssert : Assert
{
public static void IsPageLoaded(string url)
{
// Do Stuff
bool stuff = false;
if (stuff == false)
{
throw new WebTestException("The page was not loaded because of stuff.");
}
}
public override void IsNull(object value, string message, params object[] parameters)
{
// Do Stuff
bool stuff = true;
if (stuff == true)
{
throw new WebTestException("OMFG STUFF HAPPENED!");
}
base.IsNull(value, message, parameters);
}
}
Michael Cowan
Aisle7
QA Manager (QA Lead)
michael.cowan@healthnotes.com
The Assert class is marked as static, which is why you can't inherit from this. We based our implementation from the Microsoft.VisualStudio.TestTools.UniTesting.Assert class, which is also marked as static.
<div> </div> <div>To tell you the truth I am not sure of the reasoning behind Assert being a static class in MSTest. I mean, NUnit's Assert is not static. I'll try to dig this out with Brad Wilson to see if I can uncover the thought
behind this before making a decision for our framework.</div> <div> </div> <div>- Federico</div>
When you talk to the Test team, you should ask if they have considered not marking the Assert class as static, instead create an empty constructor and mark it protected. Then mark each public Assert Method as static.
This should perform exactly the same as it does now, but allow people to inherit it.
Michael Cowan
Aisle7
QA Manager (QA Lead)
michael.cowan@healthnotes.com
public class AutomationAssert
{
/// <summary>
/// Constructor
/// </summary>
/// <remarks>
/// We do not want an instance of this class created but we may want
/// to inherit from it and add more static members.
/// </remarks>
protected AutomationAssert()
{
}
#region IsUrlLoadedWithNoErrors
/// <summary>
/// Asserts that the correct Url was loaded in the browser and that it contains no
/// errors.
/// </summary>
/// <param name="expectedUrl">The exact URL to compare against the address line of the browser</param>
/// <param name="browser">A valid <see cref="WatiN.Core.IE"/> object that that has loaded the page to check.</param>
/// <param name="useAbsolutePathOnly">
/// A <see cref="System.Boolean"/> that determins if the passed in url shold be compared using
/// <see cref="System.Uri.AbsolutePath"/> (<see langword="true" />, or if the entire Url, including query string'
/// should be compared (<see langword="false" />.
/// </param>
public static void IsUrlLoadedWithNoErrors(string expectedUrl, IE browser, bool useAbsolutePathOnly)
{
...
}
// ...
// ...
}
Michael Cowan
Aisle7
QA Manager (QA Lead)
michael.cowan@healthnotes.com
Michael, there is a small caveat with our Assert that you probably don't care about, but worth explaining:
Since the lightweight framework can be plugged into our bigger automation framework (a library that includes things like server manipulation to create virtual directories), there are various extensibility points in LTAF to support our "heavy weight" framework.
One of them is the "IAssertResultHandler" (exposed through the static ServiceLocator.AssertResultHandler), which lets an external library handle what to do when an assert passes or fails. If you care about this, make sure to call the static protected methods
"OnAssertPassed" and "OnAssertFailed" instead of throwing the exception directly from your custom assert. For example:
public class CustomAssert : Assert
{
public static void MyCustomCheck(bool pass)
{
if (pass)
{
OnAssertPassed("Passed");
}
else
{
OnAssertFailed("Failed");
}
}
}
If you don't plan to use this feature, then ignore all of this :P
mcowan
Member
8 Points
42 Posts
Suggestion: Allow us to extend the Assert Class.
Apr 01, 2009 03:09 AM|LINK
I think it would be really cool if I could extend your Assert Class t oadd my own Asserts and override existing ones, but some mean person sealed the class on me!
I want to do something like this:
public class AutomationAssert : Assert { public static void IsPageLoaded(string url) { // Do Stuff bool stuff = false; if (stuff == false) { throw new WebTestException("The page was not loaded because of stuff."); } } public override void IsNull(object value, string message, params object[] parameters) { // Do Stuff bool stuff = true; if (stuff == true) { throw new WebTestException("OMFG STUFF HAPPENED!"); } base.IsNull(value, message, parameters); } }Aisle7
QA Manager (QA Lead)
michael.cowan@healthnotes.com
farmas
Participant
1164 Points
259 Posts
Microsoft
Re: Suggestion: Allow us to extend the Assert Class.
Apr 02, 2009 02:28 AM|LINK
The Assert class is marked as static, which is why you can't inherit from this. We based our implementation from the Microsoft.VisualStudio.TestTools.UniTesting.Assert class, which is also marked as static.
<div> </div> <div>To tell you the truth I am not sure of the reasoning behind Assert being a static class in MSTest. I mean, NUnit's Assert is not static. I'll try to dig this out with Brad Wilson to see if I can uncover the thought behind this before making a decision for our framework.</div> <div> </div> <div>- Federico</div>MetalAsp.Net
All-Star
112085 Points
18242 Posts
Moderator
Re: Suggestion: Allow us to extend the Assert Class.
Apr 02, 2009 02:36 AM|LINK
I may be way off on this one, but would using Extension Methods work for you?
farmas
Participant
1164 Points
259 Posts
Microsoft
Re: Suggestion: Allow us to extend the Assert Class.
Apr 02, 2009 04:38 PM|LINK
I don't think extension methods are allowed on static classes. At least not currently.
mcowan
Member
8 Points
42 Posts
Re: Suggestion: Allow us to extend the Assert Class.
Apr 02, 2009 06:00 PM|LINK
When you talk to the Test team, you should ask if they have considered not marking the Assert class as static, instead create an empty constructor and mark it protected. Then mark each public Assert Method as static.
This should perform exactly the same as it does now, but allow people to inherit it.
Aisle7
QA Manager (QA Lead)
michael.cowan@healthnotes.com
mcowan
Member
8 Points
42 Posts
Re: Suggestion: Allow us to extend the Assert Class.
Apr 02, 2009 06:04 PM|LINK
Example from my old WatiN project
public class AutomationAssert { /// <summary> /// Constructor /// </summary> /// <remarks> /// We do not want an instance of this class created but we may want /// to inherit from it and add more static members. /// </remarks> protected AutomationAssert() { } #region IsUrlLoadedWithNoErrors /// <summary> /// Asserts that the correct Url was loaded in the browser and that it contains no /// errors. /// </summary> /// <param name="expectedUrl">The exact URL to compare against the address line of the browser</param> /// <param name="browser">A valid <see cref="WatiN.Core.IE"/> object that that has loaded the page to check.</param> /// <param name="useAbsolutePathOnly"> /// A <see cref="System.Boolean"/> that determins if the passed in url shold be compared using /// <see cref="System.Uri.AbsolutePath"/> (<see langword="true" />, or if the entire Url, including query string' /// should be compared (<see langword="false" />. /// </param> public static void IsUrlLoadedWithNoErrors(string expectedUrl, IE browser, bool useAbsolutePathOnly) { ... } // ... // ... }Aisle7
QA Manager (QA Lead)
michael.cowan@healthnotes.com
farmas
Participant
1164 Points
259 Posts
Microsoft
Re: Suggestion: Allow us to extend the Assert Class.
Apr 02, 2009 06:14 PM|LINK
Yeah, I just checked this internally and we ARE removing the static from the Assert class.
The next drop is going to be released Monday or Tuesday. It will contain this change.
- Federico
farmas
Participant
1164 Points
259 Posts
Microsoft
Re: Suggestion: Allow us to extend the Assert Class.
Apr 05, 2009 01:35 AM|LINK
Michael, there is a small caveat with our Assert that you probably don't care about, but worth explaining:
Since the lightweight framework can be plugged into our bigger automation framework (a library that includes things like server manipulation to create virtual directories), there are various extensibility points in LTAF to support our "heavy weight" framework. One of them is the "IAssertResultHandler" (exposed through the static ServiceLocator.AssertResultHandler), which lets an external library handle what to do when an assert passes or fails. If you care about this, make sure to call the static protected methods "OnAssertPassed" and "OnAssertFailed" instead of throwing the exception directly from your custom assert. For example:
public class CustomAssert : Assert { public static void MyCustomCheck(bool pass) { if (pass) { OnAssertPassed("Passed"); } else { OnAssertFailed("Failed"); } } }If you don't plan to use this feature, then ignore all of this :P
- Federico
mcowan
Member
8 Points
42 Posts
Re: Suggestion: Allow us to extend the Assert Class.
Apr 05, 2009 06:06 PM|LINK
Very clever! Let me think about this for awhile. The ability to hook into the test engine and perform an action of failures is interesting....
We could send emails on test failures in special cases (like when testing a nightly build ..)
Hmm .. Very interesting. Thanks
Aisle7
QA Manager (QA Lead)
michael.cowan@healthnotes.com