This project is read-only.

How can i specify that action cause Debug.Fail?

Mar 24, 2009 at 4:48 PM
I'd like to test this behavior:
void MyMethod(string param)
    Debug.Assert(param != null); // or something causing Debug.Fail call

in elegant Specificity-like manner:
Specify.ThatAction(() =>

Have an idea?
Mar 24, 2009 at 7:26 PM
I'm not sure I understand.  For testing, Specificity already has the Specify.That(param).ShouldNotBeNull() syntax.  If you're wanting to use this outside of testing for argument verification (I'd suggest you throw an appropriate ArgumentException instead of causing Debug.Fail), you'd have to roll your own, but could follow the same design pattern.


Argument.For() would return an Argument<T> instance, and ShouldNotBeNull() would be an extension method for that type.
Mar 24, 2009 at 7:37 PM
I should read more carefully.  I see what you're trying to do now.  I'd say what you want to do is setup a TraceListener in order to cause Debug.Assert to throw an exception.  Haven't looked closely, but this article might help:
Mar 24, 2009 at 7:45 PM
Here's another interesting blog post related to this:  I can see the benefit in this, and might consider adding something in the library to simplify what's necessary to set this up.  I just have to think about the most appropriate way to do so, that remains test framework agnostic.
Mar 26, 2009 at 8:46 AM

Another crazy idea (being new to something allows to think not standardly :)

  public static class ActionDecoratingExtentions
  public static Aspect<Action> ExecutedInBackgroundThread(this Aspect<Action> self, AsyncCallback callback, object state)
   Action action = self.Value;
   Action background = new Action(() =>
    IAsyncResult asyncResult = action.BeginInvoke(callback, state);
   var aspect = new Aspect<Action>(background);
   return aspect;

and use-case:

   Specify.ThatAction(() =>
    new Button().IsEnabled = true)
   var element = new Button();
   Specify.ThatAction(() =>
    element.IsEnabled = true)
     .ExecutedInBackgroundThread(null, null)

Mar 26, 2009 at 2:10 PM
I'm not sure that the callback and state are meaningful in this scenario, but otherwise this looks like a fine addition.  Thanks for the idea.