I have created a number of (separate) CodedUI projects within Visual Studio 2013, in order to test the basic functions of a website.
Test-cases are created as separate projects, as I expect some (or all?) of them to change over time, and thus to ensure 'modularity' of capture for ease of subsequent maintenance.
Now, I see I can easily create an Ordered Test within each project, which will allow the same test-case to be run and re-run as many times as I wish; But, it's not obvious to me how I can create an Ordered Test whereby I can add different test-cases created as different projects. Certainly, not directly.
Is it possible?
Also, can I rename the Ordered Test list and save it to a separate folder where I can store differing Ordered Tests to test functionality, as I wish?
Ideally, I'd like to create an Ordered Test external to any specific project, so I can go into any project I wish and add whatever tests I wish, as the test-environment is always the same.
you should have created a single project for your application. To ensure 'modularity', coded ui has given us the option of creating different UI Maps within a same project. Each UI MAP will represent a module of your application. This approach will give you easy maintenance and it will also help you to create ordered test cases which contain test cases from different UI Maps.
for more details please see this link
https://msdn.microsoft.com/en-us/library/ff398056.aspx
Thanks
Yes, I sort of see that. And I guess it's easy enough to move the code to become separate 'solutions' within a 'project'.
However, I want to work with TFS server too, so will look at the MTM route as well.
But it may be that I need my captured CodedUI to be 'solutions' within a single project too - though I really want my modules to be 'stand-alone' projects for safe-keeping.
Will investigate further.
Related
I have created three different solutions for three different clients, but those solutions are for an app that have the same features, classes, methods, resolution, except for the images, XML resource files, and a web service reference, that are specific for each one.
I would like to have just one solution for all those apps, that I could open in VS2010 IDE for edition, without errors. So, when I need to build or publish an specific app, I just set the client which one I need to, and go ahead to building or publishing.
It is important to consider that XML file names will be the same, as classes and images names too. The difference will be the content, but the name will always be the same.
My intention is to reduce my effort to maintain many solutions, having just one solution to work with.
In my company, we will have more than those three clients soon, so I am worried about how to maintain that. The best way will be have just one solution and when I need to generate a new app for a new client, I have just to change/include a few things (like some resources and images) and compile to a new client folder.
Is it possible? If so how?
One option would be to have a master solution which had the following
A "Template" project that contained your actual application and all of the shared code
Projects for all of your clients
In the projects for your clients, you could have links to the files in your files that come from your shared project. Then, in each of those projects, you could add the files that are only specific to them.
With this kind of structure, whenever you made a change to your Template project, all of the client projects would be updated as well because they just have pointers back to the Template project.
A good reference for this kind of setup would be the Json.Net Code Base. There he has a solution and project for all of the different configurations, but they all share the same files.
In terms of ensuring that the xml files are named properly, you might just want to put some checks into your main application to ensure that it has all of the files needed or potentially add a check into your build process.
There are many ways you could look to tackle this.
My favorite would be to run some sort of pre-build step - probably outside of Visual Studio - which simply replaces the files with the correct ones before you do a build. This would be easy to automate and easy to scale.
If you are going to be building for many more than three customers, then I think you should look to switch from Visual Studio building to some other automated build system - e.g. MSBuild from the command line or from something like TeamCity or CruiseControl. You'll find it much easier to scale if your build is automated (and robust)
If you don't like the file idea, then there are plenty of other things you could try:
You could try doing a similar step to above, but could do it inside VS using a pre-Build step.
You could use Conditional nodes within the .csproj file to switch files via a project configuration
You could look to shift the client-specific resources into another assembly - and then use GetResourceStream (or similar) at runtime to extract the resources.
But none of these feel as nice to me!
I'm having trouble organising unit tests in Visual Studio. Once the tests are in test lists, changing namespaces, changing TestClass names etc. blows away all of the test list organisation structure. I case see in the solution's vsmdi file that each test and test list gets a unique GUID, which changed is the path changes, but I can't see any way of updating the test lists to use the new GUID of the new location.
Perhaps there is a tool I am missing to relocate tests without breaking the structure?
Unfortunately the test list is not clever enough to keep track of changes like renaming classes or methods - if you change something the test ends up in 'tests not in a list', and the vsdmi file is regenerated as you have discovered. For this reason, I tend not to use test lists or check vsdmi files into source control.
Instead, I use the 'group by' pull down in the test list editor window, and group by project or full class name (which makes it important to use namespaces consistently).
In VS 2011 test lists are deprecated, so I don't expect this to be fixed.
I'm starting to develop and organize tests for a very large Visual Studio solution. (Yes, I know that tests should have been developed along with the code rather than when the project is nearly complete, but things are what they are.)
I've seen similar questions about organizing unit tests in Visual Studio solutions, but I didn't see any that address integration tests as well. I would appreciate some guidance about where to place test projects so that they don't clutter up the already large code base.
Here's the basic hierarchy of things within the solution. (All items not ending in .proj are folders within a project or Solution Folders.)
HardwareServices
HardwareService1
HardwareService1.Core.proj
HardwareService1.Host.proj
HardwareService1.Service.proj
HardwareService2
HardwareService2.Core.proj
HardwareService2.Host.proj
HardwareService2.Service.proj
Infrastructure
MyApp.Database.proj
MyApp.Infrastructure.proj
MyApp.ReportViewer.proj
MyApp.SettingsManager.proj
AppModules
AppModule1.proj
Common
Reports
Services
ViewModels
Views
AppModule2.proj (similar structure to other AppModules)
AppModule3.proj (similar structure to other AppModules)
Modules
ComputeEngine.proj
Footer.proj
Header.proj
CommonServices.proj
My thought was to make a Solution Folder called "Tests" and then mimic the hierarchy above, making one test project for every production code project. Within each test project, I would make folders called "UnitTests" and "IntegrationTests".
My focus is to create a consistent naming/organization scheme so that there's no ambiguity about where new tests should go and where to find existing tests. Given the large size of this project/application, I'd like to get the structure pretty solid right out of the gate so that it's not a pain later.
Thank you for your time and advice.
The naming convention that our company adopted was the use of projectName.Tests.Unit and projectName.Tests.Integration.
With your existing structure you would have something like this:
HardwareService1
HardwareService1.Core.proj
HardwareService1.Host.proj
HardwareService1.Service.proj
Tests
HardwareService1.Core.Tests.Unit
HardwareService1.Core.Tests.Integration
If you keep your tests folder along with the root folder you don't have to mimic the complete structure again as the tests are right with the respective project.
side note
By having the project name having a consistant Tests.Unit it helps assist in running unit tests in your build script as you can run tests with a wild card search like **\*tests.unit*.dll
At the end of the day, project structure can be very subjective so do what makes sense in your environment and makes sense to your team.
What's the purose of .vsmdi file? Do I need to check into the source control system?
The VSMDI file is created by Visual Studio when you create a test project for the first time. It contains a list of all tests that Visual Studio can find in your solution assemblies and allows you to divide your tests into so-called test lists. These test lists can be used to categorize your tests and let you select a subset of tests for execution.
You can use this mechanism for running sub-selections. However, you can also (freely) assign multiple test categories to a test, which enables you to achieve the same, in a more flexible way. And with the known issues with VSMDI files, like uncontrolled duplication of these files and obsolete tests being listed with a warning icon, it might seem the better way to do things like this.
My overall suggestion is: check-in your default generated .vsmdi file. This will prevent Visual Studio from (re-)generating such files on your own and your team members systems when new test projects are added. Decide on usage of test lists or assigning categories to tests directly based on your usage experience. Test lists are easy to start with, but less suitable is you want to have flexibility for a large set of tests.
It's used for Testing in Visual Studio. If you don't do testing in Visual Studio, I wouldn't worry about it. But if you do, and you have hundreds of tests it might be worth keeping.
I seem having difficulty in understanding the reason behind the need of having many projects inside one solution (in my case visual studio 2010 with c#).
The only use that comes to mind is if I am creating a new classes I can test them in a console application first, then add another project to the solution to use these classes with the project that I want.
kindly guide me to the correct way, thanks.
A typical project might have a UI, a data layer, a services layer, and a domain layer, as well as some tests. A typical arrangement would be for each of these to exist as their own project file. The solution would contain all of these projects so that you can make modifications and debug different parts of the app at once.
If you're just starting out, you probably cram all of this stuff into one project. That's fine for learning, but is an absolute mess for maintainability and reusability.
There are 3 main reasons that immediately come to mind for splitting your solution into multiple projects: Reuse, Encapsulation, and Project-specific settings.
Reuse
You may have a Utilities project that is shared between more than one solution. You may also have data access and business rules that are defined in class libraries, but are shared between multiple UI projects, such as having a business application that has a web interface, a desktop interface, and web services. They all need to share the same logic and data model, so you wouldn't want to replicate it in each solution separately.
Encapsulation
Another reason is to achieve encapsulation, one of the main principles of OOP. Your classes may have internal methods and properties (or the classes themselves may even be defined as internal), which makes them only visible to other classes in the same project. If it's there to achieve a specific purpose but not something that should be accessible to all, by splitting your classes across separate projects you can make those properties, methods, and classes visible to your classes, but hidden outside the scope of your project.
Project-specific settings
There are certain project types that behave completely differently from one another. A Web Project is different from a Windows Forms app, which is completely different than a WPF app. This kind of goes along with #1 and trying to achieve code reuse; since you can't have a single project that is a website AND a Windows Forms app AND a WPF app, you create each UI as its own project and put as much logic as possible into a separate project that can be shared between all of the UI projects.
A couple possible reasons off the top of my head:
a project may be useful in more than one solution
simple organization utility - just like you might have classes in separate files even though a single source file can hold multiple classes just fine.