I am new to SpecFlow and I am wanting to reuse steps/tests (.feature files essentially) between solutions. I know there is a way to reuse steps between projects in the same solution by adding a reference to the project but I'm not sure exactly how to do essentially the same thing to a different solution. Thanks for any help on this one.
You cant reuse .feature files but you can reuse step definitions and hooks.
You will have to add reference to the project.
Here is the link how to reference a project in Visual studio: Link
I do not think it is possible to use steps from a different solution. You will need to include them in your working solution somewhere to use them. I don't think Visual Studio has the option to let you use inter-solution code unless you have compiled it and reference it within your working solution.
Doing this is a bit of an anti pattern. The reason for having feature files is to talk about WHAT the application does and WHY its important. So feature files should contain things that are unique to your application domain, and there won't be much overlap between projects
When you write features this way even common functionality isn't really worth sharing, because the complexity outweighs the simplicity of doing things again.
For example logging in is ripe for sharing between applications but all you need in a feature is
Given I am registered
When I login
Then I should be logged in
This is so simple that its easier to just write another one for your second application.
Most steps that people have shared other the years are all about HOW things are done e.g. clicking on things, filling in fields etc.. These generally lead to bloated scenarios and again the cost outweighs the benefits.
If you still feel there is alot of shared behaviour between your applications you may have an architectural problem where you need to extract the shared behaviour into its own application, and have your applications delegate responsibility.
Related
I'm still learning .NET (specifically C#), and I'm curious as the advantages of creating and referencing a dll versus having a multi-project solution? I have the opportunity to do either one, but I'm not sure which would be better. The projects that would be dlls are rather small, but will potentially be reused. Should size and reusability be a factor when making this decision? Thanks for any and all help.
You're still technically referencing other assemblies as each project generates an assembly.
One benefit of having a multi-project solution is that you don't need to build two different solutions- if you change code in both projects the whole solutions builds in one step. Also you can debug both projects at the same time (which is possible with separate solutions, but trickier).
Size may be a factor in build times, but unless they are huge it shouldn't be a huge issue. If projects are used by other solutions it may make sense to keep them in separate solutions so you can control the build process better.
Having separate solutions can also help you keep the interfaces constant since it's moderately harder to change interfaces through the whole stack.
Each project will still output it's own assembly, but grouping projects does make debugging and building easier.
If you are confident that you can reuse the individual projects in the future, start with a multi project solution. Design your projects carefully to minimize interdependence. If you do a good job of this, it shouldn't be too hard to separate them at a later date when you decide you want to develop an individual project independently from the whole solution.
If the assemblies aren't going to be shared amongst other projects I'd just have them in the same solution.
If the code is shared between projects that's different. I tend to treat code which is shared between projects the same way as any other third party binary - that is, I take a copy of the DLL at a specific version and reference the DLL.
The advantage of that is that, in 6 months or a year down the line when both projects that share the code are on different release schedules, each one has complete control as to when it takes the hit of updating the shared code and dealing with potentially breaking changes.
If you've just built the shared code directly into your project you're at the mercy of changes any other project requires - not a good place to be!
when you are initially developing the consuming programme i find it easiest to have a multi-project solution. but when later you develop another programme that also consumes teh same dll's, just reference tehm.
I would suggest you to add library project and you referencing project in the same solution. You reference the library project using Project reference. That would help you to debug and maintain your code better.
I am in the process of designing a web application which will have multiple installable modules that provide different functionality. There's a lot of common stuff going on here and I have 3 C# class libraries that I know will be easy to use on different projects.
The bit I am stuck on is the actual website itself. Ideally I'd like to make an ASP.NET page library that can be re-used over multiple projects but I understand that this is not possible.
How do you guys structure your website projects so that pages can be re-used across multiple projects? So far the only solution I've come up with is to create a repository in SVN and have it referenced in the svn:externals properties of the main project. This allows me to add pages to that directory that are common to all websites, and I know I will be able to use this to check them out to other projects. However, I feel this is a bit clunky and will cause problems when creating new projects (there'd be a number of steps to creating the new solution, ensuring that the right externals are in place).
Is there a better solution? What is the best way when you want to share common ASPX files across multiple client projects? How do you manage changes against them?
Thanks in advance!
EDIT:
Many thanks to David for his response. I've had more thought on this and thought I'd list some of my more concrete ideas/concerns. Firstly, a bit more about the project(s). Primarily, it's a CMS. However, we also have clients that will want CRM, and there's also clients that want neither and want an entire bespoke system from the ground up.
In my original post above, I spoke about having subdirectories of the main root (e.g, cms), using svn:externals to allow easy re-sharing of web pages across multiple projects. I am beginning to think this is the only way to do this. One thing that bothered me was if the client's url was:
http://www.shotgunanddribble.com/cms/content.aspx
However, I think I can use the Application_BeginRequest to mitigate horrible urls by rewriting them according to the configuration of the client's site. E.g, if a customer was just a CMS I could rewrite their Top-level-domain to /cms/. Same with if they were a CRM. If they were both:
http://www.shotgunanddribble.com/ -> /cms/
http://crm.shotgunanddribble.com/ -> /crm/
Is there any downside to using these kinds of rewrites? I think that, unless anyone else has any magical ideas, svn:externals is my only hope.
The actual code is easy enough to put in other assemblies and inherit from, but the ASPX files are definitely a different story. How about a common library of user controls to contain most of the display content, and each project would have its own pages which mostly just frame the user controls? I've never tried it, so there may be some "gotcha" that I'm just not picturing right now.
I googled this a little but couldn't find a good result.
Right now I'm building a web site and I'm trying to make it as correct as possible from a design point of view from the beginning.
The problem I'm now facing is that when deciding to start with logging I needed a project to place this code in. As I could not find a suitable place in my currect projects I thought: hey, why not a logging class library?
Is there a general guideline on how many projects you should have? I know this would be a rather small project but it would be nice to entirely get it out of my way!
Any hints are appreciated :)
Absolutely you should have a logging library. And if you're going to make this as 'correct as possible from a design point of view' and your proect is less than trivial then you should definitely have some number of projects. The thing is, we have no idea what you're working on besides the fact that it's a web app. It's the biz domain that often determines how complex your solution has to be.
I'd go for a three-tier architecture for a small project.
This would include:
Application Layer
Business Layer
Data Layer
but if you want to add logging, it would be best to create another project. This would also help you so that if you want to add logging to another application, you can just include the logging project.
Either way would work, if you are concerned about project limit in a solutions. Don't be.
I myself would put it in a separate project or a utility project.
We have a solution with 200+ projects. The downside is long load time in Visual Studio. But past that the only issue is making sure you have enough RAM.
Also, MSBuild.exe has built-in support for SLN files, so look into using that instead of Visual Studio if you are doing automated builds.
"That which changes together should be packaged together", I forget where that guideline comes from (Code Complete maybe?).
In other words your assemblies (projects) should represent a coherent abstraction in the same way your classes/objects do at a lower level.
So yes, a separate logging project is the right way to go (although do check out log4net or Microsoft's logging block before you roll your own!)
Put a logging into a separate project is perfectly fine.However it really depends on the scope of your project.I normally setup my project like this
YourProject.Web(web project)
YourProject.Core(all the business logic)
YourProject.Web.Tests(Watin tests)
YourProject.Web.Core.UnitTests(Unit tests)
YourProject.Web.Core.IntegrationTests(Integration tests)
I suggest you to download some open source Project from asp.net to see how the project have been organized.
When/where do you decide to split a large Visual Studio project into smaller multiple projects? If it can be reusable? when project is too big? (but how big is too big?)
and When you do split the project, do you,
group by database tables
group by similar functionality
other..
Pros of many projects:
Easier to isolate code for unit testing. I like to isolate code that has a dependency on a big external server thing, for example code that talks to the SMTP server gets its own assembly, code that talks to the database gets it's own assembly, code that talks to the webserver, code that is pure business logic like validations.
Pros of few projects:
Visual studio goes faster
Some developers just don't get your vision
about dividing up responsibilities
and will start putting classes
everywhere, so you end up with the
pain of extra projects and the
benefits of putting everything into
one project.
Each project has a configuration and when you make a decision about project configuration, often you have to make the same chagne everywhere, such as setting or changing the strong name key
Pros of many Solutions
You hit the maximum project level later.
Only the stuff in your current solution gets compiled everytime you hit f5
If the project isn't expected to change in the life of your application, why re-compile it over and over? Call it done and move it to its own solution.
Cons of many Solutions
It's up to you to work out the dependencies between solutions and manually compile the dependencies first. This leads to complicated build scripts.
Projects should be cohesive. Logic should be related, and accomplishing a similar goal
This answer will depend on the size of the product you are supporting. In general we organize our projects along domain and logic. And we will divide those even further, the more you divide the more organize you must be, or you are going to hit the dreaded recursive dependency issue.
When I do choose to break up project it is when it grows to be too large or two areas are becoming too similar.
When complexity is rising I do not split by tables, i generally split functionality.
Re-usability is another excellent time to reduce lines of code, as well as introduce a new project. However be careful how many "utility" libraries you introduce because they do have impact on readability/understandability.
I do not think there is a line in sand that says, if you hit 3k SLOC, you have too much. It all is contextual.
I always have several projects (and therefore a solution) , instead of one project with all of my source in it.
In some cases, it is unavoidable because you are using and open source library and want to be able to debug it. But more pragmatically, I typically have my applications provide functionality via plugins. This allows me to change the behavior or offer a user-selectable behavior at runtime. In the non-plugin case, it allows you to update one portion of your program without updating everything. There are also cases where you can provide the main apparently, and only download the modules / assemblies when you need them.
One other reason is that you can create smaller test apps to exercise an assembly, rather than building a very large solution and potentially requiring a user to execute several (and irrelevant) GUI operations before even reaching the part you want to test. And this isn't just a testing concern -- maybe you have less-savvy users in your organization that only want to be presented with the bits that concern them.
When the overall purpose of the project remains the same, but the number of classes is becoming large, I tend to create folders and namespaces to better group functionality within the project. Classes that are coupled to each-other tend to go in the same folder/namespace, so that if I need to understand a given class, the related classes are nearby in the Solution Explorer. I usually only create new projects if I realize that a particular piece of functionality is very different in purpose or if there is a common dependency between existing projects.
I usually wind up with a few relatively small Framework projects that define interfaces for loose coupling between other projects, with larger projects for the different types of concrete functionality. That's always at least one project for the UI and one project for logic and data (often split into two projects if the data layer becomes very large in its own right.)
I move code to a new project, if it has general functionality (theoretically) usable by other projects too. If the project is large, because it represents a complex problem, then namespaces provide a great way to bring order in the code. Here you can for example introduce a (sub-)namespaces for each SQL table, etc. etc.
I want to be able to refactor 500 projects at the same time.
I have about 20 solutions and I don't have a master solution with everything because I haven't figured out a way to auto generate it.
Any suggestions?
Thanks
Edit
I've tried slnTools from codeplex to generate a solution and visual studio pretty much took down the entire operating system. Not sure if it was the solution not being generated properly or if it was just a limitation of Windows / Visual Studio.
To create the huge solution, you should be able to start with a macro vaguely like this:
Dim d As New System.IO.DirectoryInfo(System.IO.Directory.GetCurrentDirectory())
For Each f As System.IO.FileInfo In d.GetFiles("*.*proj")
DTE.Solution.AddFromFile(f.FullName)
Next
DTE.Solution.Close(True)
Before you start the mega-refactoring, I'd suggest you use something like NDepend to analyze the dependency structure of the code, and compare it to your goals for refactoring. You'll only need projects in memory that will be affected by a particular refactoring. If you can limit the set that are needed, you'll greatly benefit.
If you can't get them all into memory, you should still be able to partition the work - you'll just have to repeat it. Consider the case where you've got a single class library that is used by ten other projects, and you want to refactor the public interface.
Save a copy of the class library
Load Project 1 and the class library, and do that refactoring. Close the solution.
Restore the class library from the saved copy.
Load Project 2 and the class library, and do that refactoring again. Close the solution.
etc. Finally, keep the last changed copy of the class library. If you really repeated the refactoring, all ten projects should be happy.
I'd also take the opportunity to refactor towards flexibility, so that you won't need to do this again. Accessing the class library through interfaces or facade classes can isolate you from changes in public interface.
What exactly is it you want to refactor? ReSharper is probably the best known tool for large scale refactorings... but whether it is appropriate depends on what you want to do.
You could always download the trial and give it a whirl...
If they all share the same business / data domain libraries, you can refactor that and then update the references in the projects.
More likely you want to create that business / data domain from these distributed projects. I don't know the details, but I'm willing to bet that smashing 20 solutions together won't help you in refactoring out common code.
I would start small, and create a new solution that is your common application bits.
Pull the obvious pieces of common code into that solution, and reference it's compiled dlls in your other projects.
Review your projects and repeat until you have something resembling the structure you are looking for.
I think there is nothing done to satisfy your need.
You could try slnTools to see how manipulate sln files, and merge them into one .sln file.
But I'm not sure if Visual Studio can handle well 500 opened projects.
You may be better of with a smaller number of projects that each have more files in each. It would not be that hard to write a C# programm the created a project file containing all your souce files.
Visual studio may or may not be able to cope with it then...