Deployment Items for Mstest to include files used in your test

[nitro52]

I just created a blog on how to include files in your specflow tests
(at least mstest as i'm not sure if the other engines have the same
issue) but i was thinking that this could be an area that was a little
more friendly.

http://rburnham.wordpress.com/2011/09/01/loading-external-files-for-image-comparison-using-specflow-and-mstests/

The work around is to create a separate partial class that you add the
DeploymentItem attribute to but if the feature gets renamed this
partial class doesn't. It would be good if there as a way we could
include a file or folder and have the correct attributes added to the
generated code.

What do you think?

[Jonas Bandi]

How would you imagine that this should work?
How would you make the link between this additional configuration and
the feature file?

Personally I think the MSTest concept of having to "deploy" a test is
over-complicating things.
As you did, partial classes are a possible workaround. I doubt that we
should invest an further ...?

--
mail: jonas...@gmail.com
web: www.jonasbandi.net
blog: blog.jonasbandi.net
twitter: twitter.com/jbandi

[nitro52]

How does NUnit handle this? Can it handle running a test on a remote
machine? I'm defiantly no architectural expert so i think someone else
might have a better idea of how it could work. From a usability point
of view perhaps a method or class attribute that can be placed on the
step definitions but this might be a bit backward for the code
generation. The only other way I can think is to contain it on a
config file? Perhaps you could have some deployment class that could
allow you to tie an item to a feature or scenario.

On Sep 1, 10:21 pm, Jonas Bandi <jonas.ba...@gmail.com> wrote:
> How would you imagine that this should work?
> How would you make the link between this additional configuration and
> the feature file?
>
> Personally I think the MSTest concept of having to "deploy" a test is
> over-complicating things.
> As you did, partial classes are a possible workaround. I doubt that we
> should invest an further ...?
>
>
>
>
>
>
>
>
>
> On Thu, Sep 1, 2011 at 5:40 AM, nitro52 <nitr...@iinet.net.au> wrote:
> > I just created a blog on how to include files in your specflow tests
> > (at least mstest as i'm not sure if the other engines have the same
> > issue) but i was thinking that this could be an area that was a little
> > more friendly.
>

> >http://rburnham.wordpress.com/2011/09/01/loading-external-files-for-i...

>
> > The work around is to create a separate partial class that you add the
> > DeploymentItem attribute to but if the feature gets renamed this
> > partial class doesn't. It would be good if there as a way we could
> > include a file or folder and have the correct attributes added to the
> > generated code.
>
> > What do you think?
>
> --

> mail: jonas.ba...@gmail.com

[Vagif Abilov]

AFAIK other frameworks (NUnit, XUnit, MbUnit) don't have such problems because they rely on whatever test folders contain. It's only MsTest that deploys tests in newly created folders, so you have to take care about any additional dependencies the test may have. I agree with Jonas that making generic changes to SpecFlow just to fix overcomplicated MsTest runner environment feels wrong.

Just my 2 cents.

Vagif

[Gáspár Nagy]

yep. mstest is... over-complicating the things...
i was thinking about being able to configure tag processors. e.g. the
tag processor for "di" would get the control of handling tags, like
@di:myfile,txt and it could generate whatever attribute is necessary.
Maybe this could be used for other extensions too (@async?).

What do you think?