The rules of software versioning recommend incrementing the MAJOR VERSION when there are breaking changes to the public API.
I have tried using Class View in Visual Studio and applications like dotPeek, but I have so far been unable to find a way to export a list of all public members of an assembly to either plain text or XML. Does anyone know a good way to do this?
I created a NuGet package to do this. http://www.nuget.org/packages/ApiApprover/
Basically it generates your public API as a big string, then passes it to approval tests to verify.
Approval Tests works by failing the test if the received and the approved text differs. If it differs, it can pop up a merge tool so you can review the changed, and accept them. Approval tests seemed like a perfect solution to this problem, I just wrapped the public API generation around it.
Related
As an enthusiasting refactorer, there's an IntelliJ feature that I love: "Refactor --> Change signature".
Basically, you have a function and you can decide to remove a parameter or add a new one, setting a default value. This is so convenient, so beautiful, and I dearly love it.
So when I got involved in an oldschool UFT project with maintenance tasks, I felt jaded.
It there a way to achieve this without changing each and every instance of the function? Please tell me yes. Please!
Well, no. I don´t know of any tool capable of this.
There seem to be people who created a C# adapter for the UFT test object API, enabling them to write their tests in C#, and to use VisualStudio for development of test scripts. In VS, you have the refactoring support you look for. But you don´t create UFT scripts anymore, you´d create C# apps. (Note I am not talking about the API testing aspect of UFT, which uses C# anyways -- I am talking about the VBScript test scripts for GUI tests and BPT components.)
UFT itself is not capable of doing real static code analysis. (Let this statement drown a minute, and you´ll agree: it´s true.)
Adding this to the fact that the UFT´s IDE is, let´s say: sub-optimal, this led to the development of Test Design Studio (TDS), a VisualStudio "feel-alike" subset of VS for UFT (VBScript) scripts. You can check it out here: http://www.patterson-consulting.net/products/test_design_studio/Default.aspx
Among other things, TDS does static code analysis for UFT scripts in a pretty complete way (as far as an interpreted variant-typed language like VBScript allows that at all), and the author of the tool seems to be thinking about adding refactoring features like the one you asked for, but -- this has not happened yet. It will probably come only if demand is high.
Until then, TDS could help you:
You could simply change the signature
If TDS knows all calls (which is usually does), it will list you all locations where you need to edit -- and this happens at design-time, not at runtime
TDS allows you to specify the type of identifiers, for example: formal parameters, variables, and so on. This means you might even get warnings if you change nothing about the pure VBScript signature (which does not include type information), but do change the TDS directive of that signature parameter of which you changed the type.
This is no advertisement. I am not part of the company that developed TDS.
This is just an honest answer to the (slightly offtopic) question that I wish would have gotten years ago, asking questions like yours, and it proved to be a real lifesaver.
In summary, TDS quadrupled (or more) my productivity when creating and maintaining test scripts, especially if a large base framework is used. So I´d recommend checking out the option of using TDS to better handle changes like the ones you outlined.
I am creating a PythonAnalyzer using the following code:
var interpreterFactory = InterpreterFactoryCreator.CreateAnalysisInterpreterFactory(
PythonLanguageVersion.V36.ToVersion());
var analyzer = PythonAnalyzer.Create(interpreterFactory);
Later on I also create and analyze a simple python module, that looks like this:
name = input('What is your name?\n')
print('Hi, %s.' % name)
Then I do module.Analysis.GetValuesByIndex("name", 4).
At this moment I expected the "value" to be 'str', because that's what Visual Studio shows when I open the same file in it. However, I get 'object' instead. So it seems that the PythonAnalyzer when constructed as mentioned above lacks some important information about where to look for standard library and/or its types.
Unfortunately, the documentation on PythonAnalyzer is lacking, so I was hoping the community could help understand how to configure it properly.
Congratulations on getting so far :)
What you're hitting here is the fact that CreateAnalysisInterpreterFactory is really intended for "pure" cases, where you have access to all the code that you're trying to analyze and nothing needs to be looked up. It is mostly used for the unit tests, or as a fallback when no copies of Python are installed. Depending on precisely which version of PTVS you are using, the bare information you're getting is either coming from DefaultDB\v3\python.pyi or CompletionDB\__builtin__.idb, both of which are somewhat lacking (by design).
Assuming you have a copy of Python installed, I would suggest creating an instance of InterpreterConfiguration with all of its details, and passing that to CreateInterpreterFactory (without "Analysis").
If you're on the latest sources (strongly recommended), this may run the interpreter in the background to collect information from it (you can control caching of this info with the DatabasePath and UseExistingCache members of InterpreterFactoryCreationOptions). If you are using the older version still, you'll need to trigger a completion DB regeneration or have one that you've created through VS.
And a final caveat: this part of PTVS is currently under some pretty heavy development at time of writing, so you'll either want to keep updating the version you're working against or stick with a slightly older one. Also feel free to post questions like this on the GitHub site, as while this is technically public API, it's barely documented at all and so the best help will come from the dev team.
So, I have multiple selenium test projects in separate VS solutions and they all have the same Setup() methods which are executed before scenarios are run as well as all having the same TearDown() methods for after. Currently if a change is required for these methods, they have to be updated separately so I was looking in to centralising these methods to be used in all of the test projects/solutions.
I'm relatively new so apologise in advance but does anyone have experience of this with suggestions on approaches I could take? Is it even possible? My tests do not currently run in parallel so is this something I'd need to look in to?
How if you change code be
[OneTimeSetUp] and [OneTimeTearDown]?
in my opinion you should create one class for setup include setup and tear down then in yor test add setup like this public class HREmployeeList:Setup
Hopefully help or not just check this below link
http://toolsqa.com/selenium-webdriver/c-sharp/how-to-write-selenium-test-using-nunit-framework/
One thing you could do is create a new project that contains the functions for setup and teardown and then include that compiled dll in all the other projects. If you need to make a change to setup/teardown, you make the change and compile a new dll and the code change is passed to all the other projects.
Keeping long story short - you need to create a Meta framework.
By concept Meta frameworks provide a method of solving the problem with automating multiple pieces as part of a larger automation strategy. Testers define independent utility classes which can be generically used with any automation tool and can be reused between different automation projects as well. The framework provides an abstraction layer that allows the separate automation pieces to be executed and have their results reported back in a standardized way.
I have a post on the topic, so feel free to take what you need form there.
Since you've tagged VisualStudio, I'll share first the approach my team did use for sharing common functionality across Test projects. What you need is a private Nuget server. Each team compiles and supports a Nuget pack based on the service it provides. For example Selenium code, API calls etc.
Next and probably closer to your case solution would be to utilize git submodules and share the Test harness engine between your projects.
Both approaches will benefit of a Fixture Setup Patterns like Shared Fixture Construction.
Ok, before I begin I realize that there is a lot of documentation on this subject but I have thus far failed to get even basic colourization working for VS2010.
My goal is to simply get to a point where I can open a document and everything is coloured red, from here I can implement the relevant parsing logic.
Here's what I have tried/found:
1) Downloaded all the relevent SDK's and such- Found the ook sample (http://code.msdn.microsoft.com/ookLanguage) - didn't build, didn't work.
2) Knowing almost nothing about MEF read through "Implementing a Language Service By Using the Managed Package Framework" - http://msdn.microsoft.com/en-us/library/bb166533(v=VS.100).aspx
This was pretty much a copy and paste of all the basic stuff here, and also updating some references which were out of date with the sample see: http://social.msdn.microsoft.com/Forums/en-US/vsx/thread/a310fe67-afd2-4592-b295-3fc86fec7996
Now, I have got to a point where when running the package MEF appears to have hooked up correctly (I know this because with the debugger open I can see that the packages initialize and FDoIdle methods are being hit).
When I open a file of the extension I have registered with the ProvideLanguageExtensionAttribute everything dies as if in an endless loop, yet no debug symbols hit (though they are loaded).
Looking at the ook sample and the MEF examples they seem to be totally different approaches to the same problem. In the ook sample there are notions of Clasifications and Completion controllers which aren't mentioned in the MEF example. Also, they don't seem to create a Package or Language service, so I have no idea how it should work?
With the MEF example, my assumption is that I need to hook into the "IScanner.ScanTokenAndProvideInfoAboutIt" to provide syntax highlighting? Which would be fine if I could ever hit this method.
So my first question I guess is which approach should I be taking here? Or do they both somehow tie together?
My second questions is, where can I find a basic fully working project that implements bog standard basic syntax highlighting and intellisense or VS2010?
Thirdly, in the MEF example when I created a Package there were a bunch of test projects created for me. I appears that the integration tests launch the VS2010 test rig somehow, but the test fails. It would be good to write my service with tests but I have no idea what/how I can test each interaction so any references to testing Language services would be helpful.
Finally, please throw any resource/book links my way that I may find useful.
Cheers, Chris.
N.B. Sorry I realize this is part question part rant, but I have never been so confused.
First, the package example is not using MEF. Essentially everyplace that you mention MEF in your question is not actually MEF, but the managed package framework (MPF), also colloquially called the managed language service (MLS). You'd know if your extension was using MEF by two things: the vsixmanifest lists your assembly as containing a MEF component, and you see [Export] and [Import] attributes in the code.
The easiest way to do this is to use MEF. Since you have the SDK installed, you also have a template for an editor classifier project (under C# (or VB)->Extensibility->Editor classifier in the New Project dialog). You can certainly do this with a language service/colorizer/package, but there will be significantly more code than the equivalent classifier.
The Ook solution is the sample for this and should work; if it doesn't build/work, then can you send me email (noahric at microsoft) with what errors you are seeing so I can email the owner of that sample?
In general, you should also read my answer for the question on "How can I write a plugin for VS2010 using MEF?". That has links to other resources that should help.
Is it possible to identify classes that implement IDisposable. I was hoping to do so in the Visual Studio Color settings or with an addon.
I don't use Resharper and I have heard that FXcop has this feature. I was looking for something different than these options.
You can right click on the type and select go to definition. It should show you the public members of the class and the interfaces it implements. The object browser can also be used to see this.
However Brody's answer is usually the simplest way and works so long as someone hasn't implemented a method called Dispose but not implemented the IDisposable interface.
You can use the Class View and Object Browser to determine it. But going to the definition is the best idea as the MetaData generated will show you all the methods and the inheritance of the class
Look for the method Dispose() on the class.
Not at a risk of coming across the wrong way (so please don't take it that way), but the best way is to know your code and know the Framework. You should only need to look something up a couple of times to learn which are which. There is not really a dependable way apart from either checking if .Dispose() is a method (which always does not work, as Dispose can be private on some of the Framework classes, such as ManualResetEvent where it is protected), or by going to the definition to find it.
That is not to say that someone could not write an add-in that would do it. I don't see any issues with the technical feasibility of that. A cursory search of Google didn't turn up any existing add-ins that do it, but there might be something out there already.