1

Closed

Allow for custom IValueFormatters

description

I have some cases where I override ToString on my class under test but I'd prefer to use the DefaultValueFormatter as it display nicer formatted results for me (though there are a few properties I would like to omit). There a number ways to fix this but in the end I think allowing the user to setup their own IValueFormatter(s) would be great.
Closed Aug 25, 2012 at 2:19 PM by
All done with the public beta of Fluent Assertions 2.0

comments

dennisdoomen wrote Jul 13, 2012 at 7:43 PM

Sounds like a great idea. Do you have a particular example we could include in the specs and the demo?

AB_dreeve wrote Jul 13, 2012 at 8:09 PM

A general example case is when I have a class which I override ToString() to return only 1 or 2 properties on my class, but my class might have many more properties. Losing the default formatting and the ability to display the additional properties is unfortunate because the additional property values is often important in why a test might fail.

For example:
public class ExcelSchemaDefinition {
    public int Index { get; set; }
    public string DataField { get; set; }
    public string ColumnLabel { get; set; }
    public int ColumnIndex { get; set; }
    public string CellFormat { get; set; }
    public string PropertyName { get; set; }
    public Type PropertyType { get; set; }

    /// 
    /// Returns a string that represents the current object.
    /// 
    /// 
    /// A string that represents the current object.
    /// 
    /// 2
    public override string ToString() {
        return string.Format("Index: {0}, ColumnLabel: {1}, DataField: {2}", this.Index, this.ColumnLabel, this.DataField);
    }
}
My app wants nice short ToStrings() for various reasons, but the DefaultValueFormatter or a CustomValueFormatter helps me see whats wrong with my tests quickly.

dennisdoomen wrote Jul 14, 2012 at 7:46 AM

So you essentially want to override the default behavior for particular types? If so, what kind of API would you expect?

swythan wrote Jul 25, 2012 at 3:22 PM

MbUnit has this capability. You basically just put a [Formatter] attribute on a static method somewhere in you test assembly.

See: http://gallio.org/wiki/doku.php?id=mbunit:custom_behaviors:formatter

We use it to get sensible output for a class that has a ridiculously large number of properties (including nested properties).

AB_dreeve wrote Jul 25, 2012 at 4:01 PM

It seems that right now you assign the formatters to a list which we cannot access to make changes. Allowing us to Add and Insert into this list would be a simple solution.

Also adding the MbUnit attribute like functionality as another built in formatter might be nice as well, but if we keep your work down to a minimum then we have a better chance of seeing this :-).

Changing accessibility to that list or adding hooks for adding/inserting the custom formatters seems sufficient to me.

swythan wrote Jul 25, 2012 at 4:48 PM

@AB_dreeve I can't argue with that.

I just thought I'd mention what MbUnit did as a concrete example/answer to @dennisdoomen's question about what the API might look like.

wrote Aug 13, 2012 at 7:27 PM

Associated with changeset 80981: First attempt to support attribute-based value formatters. Not working for WP7 and SL yet.

wrote Aug 14, 2012 at 7:32 PM

Associated with changeset 81016: The AttributeBasedFormatter now also works in Silverlight and WP7. WinRT doesn't support enumerating assemblies, so we can't support this feature there.

wrote Aug 14, 2012 at 7:34 PM

.NET, WP7 and SL now will automatically find static methods annotated with the [ValueFormatter] attribute. WinRT doesn't support enumerating the assemblies in the AppDomain. However, the Formatter.Formatters collection is now public so you can add your own implementations as well.

Sign in to add a comment