I have been experimenting with SpecFlow and I have liked what I've seen and tried out so far. However, I am concerned about one thing about SpecFlow, and it is the generated code for the test template for each feature file.
Although I have not ran into problems with the test template, I have concerns about problems that may arises from the generated code, since any changes to the generated code will be blown away if I were to rerun the specFlowSingleFileGenerator.
Has anyone encountered problems with the generated code and have to make changes and maintain?
Any suggestions that will help me avoid needing to make changes for the generated code?
Thanks
- Eddy
The generated code can be easily regenerated. Delete the generated code file, and then right click on the feature in the "Solution Explorer" window. In the context menu which appears select the entry "Run Custom Tool", this will regenerate the code file.
You definitely should not modify the generated files, nor should you have any reason too.
I have had few problems with these files. Occasionally in work these files might get out of sync if multiple people are working on them, but regenerating them using the solution above usually alleviates any problem.
Related
I am facing 2 problems during checkin of design changes in TFS 2012.
When I made the some design changes (for example alignment of buttons), codes in frm file gets rearranged. Which gives me a lot of differences even though there are very few (If I manually cut and paste the code in proper place then I can see only few lines of mismatching)
If there are some unwanted changes in frm files then there will be changes in respective frx files also. My question if I undo (delete the unwanted changes in TFS ) then how can I differentiate between required and unwanted changes of frx files ?
These two things are killing my lot of time. Please help me to solve these problems.
Its not always the case, but usually the amount of churn in generated files like the frm file is caused by people by selectively checkin parts of that file. By selectively checking in parts of a generated file it causes visual studio to make more drastic changes to the file than one would expect beforehand. If you checkin the complete file a few times this behavior should go away. If it still persists, another option would be to swap the merge tooling to something that suits you better https://blog.paulbouwer.com/2010/01/31/replace-diffmerge-tool-in-visual-studio-team-system-with-winmerge/. E.g. winmerge can be modified to ignore moved sections if they are not modified.
Every VB6 project in source control faces this issue. I find it useful to break up my work into many smaller changes, and diff and/or check-in changes only in those smaller chunks. This usually makes it much clearer what actually changed.
I have been working with Pex(IntelliTests) for some time now and I wondered if it is possible to create the tests via some sort of command(or .exe) and not through the IDE(VS2015) with right-clicking the function.
I have an automated process which builds my projects and further runs my tests. However if the IntelliTests are not generated anew for the new implementation they are rather useless.
This may seem like a basic question but unfortunately I could not find any information on the internet.
A command line for IntelliTest is not yet supported. If you would like to see it supported, kindly add your vote here: https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/8623015-enable-intellitest-to-run-in-the-build-pipeline
i'm currently trying to learn bdd techniques and trying frameworks for it. the idea comes from test to code, but i want to use it in revers way if possible.
i'm currently using specflow, selenium and nunit combination. i want to open my work to anyone (non-developers) for adding new examples or test cases. let's say i have implemented all use cases but changing step orders or modifying/adding examples would enrich my test cases.
the problem is that i have to build the project for each change in feature files. is it possible to use this technique in that way?
Given I have scenarios
And I have step definitions
When I want to add new tests
Then I should be able to load .feature file as input
if not possible, i'm thinking about some parsing operation to map them with my methods, i guess there is a better way to implement this idea.
From what I understand, you want to avoid having to rebuild your test for changes in your feature file
The problem with what you are suggesting is that you are assuming your mapping is as simple as:
Feature file <---> StepDefs
But in reality whats happening is:
.Feature File<--->FeatureFile.feature.cs<--->StepDefs
The features are mapped to the step defs using a 3rd file that is auto generated when your test builds. This maps the two files together. So even if you were simply passing in a .feature file you would still have to do some kind of build in order to generate the .cs file and map the two files together.
This is a bit of a strange one, but I was wondering if anyone might have seen it before and know of a cure.
Basically, we have updated a schema and the format has radically changed. The schema was used in a number of maps, so these have also been updated.
When testing one of the maps (Visual Studio right click, test map) it claims that the test suceeds, but the resultant xml is in the old schema format and not the new updated format.
The mapper shows the correct schema, I have tried rebuilding and even redeploying just in case something was holding on to the old schema somehow, but it still maps to the old format.
Any suggestions welcome.
Cheers
Stu.
This is a bug feature of Visual Studio BizTalk projects.
In your BizTalk solution, ensure that "show all files" (at the top) is set, and then manually run through your affected Schemas, and delete the generated .xsd.cs files.
Do the same for your updated maps (btm.cs) as well, and then rebuild the project.
(BizTalk will rebuild the *.cs files)
Also, at deployment / import time, ensure that you:
Re-GAC your assemblies
Re start the BizTalk host processes
I've got a VS/TFS2010 project in which we use a generated file. Here's how it works:
There's a pre-build event that creates the file (foo.cs)
The file is included in the project.
The file is NEVER added to TFS version control.
It works great, except... People have an unfortunate habit of accidentally checking in the file. This, of course, breaks the system.
Are there any good ways to prevent this from happening? Can I at least set up some kind of watch mechanism to alert me if it does happen?
You'll need to install the Team Foundation Server Power Tools, which will include the "Forbidden Patterns" check-in policy. This will allow you to prohibit a file from being checked in based on regular expression applied to the server path.
This will allow you to simply add the full server path of the file you wish to ensure does not get added. For example:
^\$/TeamProject/Folder/foo\.cs$
I was researching this exact issue today and found this, which may be of some help: How to ignore files/directories in TFS for avoiding them to go to central source repository?
Not sure if 2010 has made this easier or not.
(Apologies, this should probably be a comment, but I don't think I have enough rep to comment.)