There is an unsaved comment in progress. You will lose your changes if you continue. Are you sure you want to reopen the work item?

2

Closed

Conventions for arrays and other multiples

description

AutoFixture has no inherent understanding of arrays or other multiples like IEnumerable<T>. Consider implementing a set of ISpecimenBuilders that relays requests for arrays etcs. to requests for many instances of the given type. It might be most
appropriate to define this as an optional set that can be explicitly added to a Fixture.

comments

Array support is implemented and will be an integral part of AutoFixture 2.0. This makes sense since arrays are first-class citizens in .NET and AutoFixture always had rather lacking support of arrays: it would create an array, but not fill it - a situation
that was neither here nor there. In AutoFixture 2.0, requests for arrays will be automatically fulfilled with a populated array of the requested type. This feature is already in the source code repository.

However, the rest of this issue will be deferred to after AutoFixture 2.0. This is because it has the potential to change how AutoFixture behaves. In general, support for multiples fall in two categories: 1) abstractions 2) concrete types. Let's look at each
in turn:

1) Abstractions:
These would be covered by requests for IEnumerable<T>, ICollection<T>, IList<T> as well as any custom interfaces or abstract base classes derived from those, but defined by the user. As far as AutoFixture is concerned, these are interfaces
just like any other interface, and will not be resolved unless explicitly addressed by a customization, or generally be an auto-mocking extension. While AutoFixture could have special-case handling for the BCL interfaces, it can't have that for custom derivatives.
Furthermore, if an auto-mocking extension is in play, which one should handle a request for IEnumerable<T>? The auto-mocking extension or the multiple-convention? As this case is at best ambiguous, my take on this at the moment is that this should be
an optional feature that can be explicitly added to a Fixture instance if desired.

2) Concrete types
This covers requests for List<T>, Collection<T> and so on, as well as derived classes defined by the user. These tend to have proper public constructors and will typically be created and instantiated by AutoFixture. However, since most of these
constructors initialize empty lists, the created instances tend to be empty. Once again, redefining this behavior is a breaking change and would require special-casing, so is better left as an optional feature.

In short, I think this feature is very valuable, but it will have to be an optional feature that can be explicitly added to a Fixture instance.