Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Apr 05, 2009 06:06 PM by mcowan
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);
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.
Apr 02, 2009 02:36 AM|LINK
I may be way off on this one, but would using Extension Methods work for you?
Apr 02, 2009 04:38 PM|LINK
I don't think extension methods are allowed on static classes. At least not currently.
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.
Apr 02, 2009 06:04 PM|LINK
Example from my old WatiN project
public class AutomationAssert
/// We do not want an instance of this class created but we may want
/// to inherit from it and add more static members.
/// Asserts that the correct Url was loaded in the browser and that it contains no
/// <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" />.
public static void IsUrlLoadedWithNoErrors(string expectedUrl, IE browser, bool useAbsolutePathOnly)
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.
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 you don't plan to use this feature, then ignore all of this :P
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