is there any vs addins that can take a class and set up all the wiring to generate the test class and methods as well as mocking the dependencies, etc. this seems like something that can be automated.
You can try to create some VS templates.
I've create some Resharper templates for mysel but they are as sophisticated as what you want.
Microsoft tried something like that awhile back, I believe, and was widely criticized for not understanding what Test-Driven Development/Design was all about.
Pex might be part of what you're looking for. It's an aid to unit testing, not a replacement for it.
There are also IoC Container frameworks (and I think mock/isolation frameworks as well) that support auto mocking, which might also help.
As Vadim mentioned, templates and snippets can take care of a lot of the boilerplate code.
I haven't used Pex or auto mocking; I just do what Vadim does.
I suspect not; even if the sigs can be automated, You'll need to provide all the cases; it can't infer what is supposed to equal what, what properties matter, what are the edge cases, etc.
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.
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.
I use HttpWebRequests pretty extensively - I've found that the Visual Studio Web Test classes (i.e. WebTestRequest and WebTestResponse etc) offer a lot of really nice methods that i'd love to start using.
But I can't seem to find a way to use these classes outside of the Visual Studio's testing framework. Has anyone done this?
Will,
WebTestRequest and WebTestResponse aren't designed to be used like HttpWebRequest and HttpWebResponse. They're mostly containers for passing various request and response data into and out of the web/load test engine in Visual Studio or MSTest.
I wrote both of the classes and even I find myself wishing I could use them for other purposes :) I've definitely had to reinvent similar querystring parameter parsing logic for other projects since then.
Josh
Environment: (C# WinForms application in Visual Studio Professional 2008)
I've been digging around a little for guidance on NUnit best practices. As a solo programmer working in a relatively isolated environment I'm hoping that collective wisdom here can help me.
Scott White has a few good starting points here but I'm not sure I totally agree with everything he's said -- particularly point 2. My instincts tell me that the closer a test is to the code being tested the more likely you are to get complete test coverage. In the comments to Scott's blog posting is a remark that just testing the public interface is considered best practice by some, but I would argue the test framework is not a typical class consumer.
What can you recommend as best practices for NUnit?
If by point 2, you mean the "bin folder per solution" -- I can see your point. Personally, I would simply add the reference to each test project. If, on the other hand, you really mean (1b) "don't put your tests in the same assembly as your code" I heartily agree with him and disagree with you. Your tests should be distinct from your production code in order to enhance code clarity and organization. Keeping your test classes separate helps the next programmer understand it more easily. If you need access to internals in your tests -- and you might since internal methods are "public" to the assembly, you can use the InternalsVisibleTo construct in the Assembly.cs file.
I, too, would recommend that, in general, it is sufficient to unit test only the public interface of the code. Done properly (using TDD), the private methods of your code will simply be refactorings of previous public code and will have sufficient test coverage through the public methods. Of course, this is a guideline not a law so there will be times that you might want to test a private method. In those instances, you can create an accessor and use reflection to invoke the private method.
Another recommendation that I would make is to use unit testing and code coverage in tandem. Code coverage can be a useful heuristic to identify when you need more tests. Lack of coverage should be used as a guide to indicate where more testing may be needed. This isn't to say that you need 100% coverage -- some code may be simple enough not to warrant a unit test (automatic properties, for instance) and they may not be touched by your existing tests.
There were a couple of issues that I had with the article. Probably the biggest is the lack of abstraction away from the database for unit tests. There probably are some integration tests that need to go against the db -- perhaps when testing trigger or constraint functionality if you can't convince yourself of their correctness otherwise. In general, though, I'm of the opinion that you should implement your data access as interfaces, then mock out the actual implementations in your unit tests so that there is no need to actually connect to the database. I find that my tests run faster, and thus I run them more often when I do this. Building up a "fake" database interface might take a little while but can be reused as long as you stick with the same design pattern for your data access.
Lastly, I would recommend using nUnit with TestDriven.Net - a very useful plugin whether you're doing nUnit or MSTest. Makes it very handy to run or debug tests with a right-click context menu.
My instincts tell me that the closer a
test is to the code being tested the
more likely you are to get complete
test coverage. In the comments to
Scott's blog posting is a remark that
just testing the public interface is
considered best practice by some, but
I would argue the test framework is
not a typical class consumer.
If your code cannot be tested using only public entry points, then you have a design problem. You should read more about TDD and SOLID principles (especially single responsibility principle and dependency inversion). Then you will understand that following TDD approach will help you write more testable, flexible and maintainable code, without the need for using such "hacks" as testing classes' private parts.
I also highly recommend reading Google's guide to testability by Miško Hevery, it has plenty of code samples which cover these topics.
I'm in a fairly similar situation and this question describes what I do keep-your-source-close-and-your-unit-tests-closer. There weren't too many others enamoured with my approach but it works perfectly for me.
Does anybody use the Class Designer much in Visual Studio?
I have downloaded the Modeling Power Toys for 2005 and have been impressed with what I've seen so far. The MSDN Class Designer Blog doesn't seem to have been updated for a while but it still looks quite useful.
Is the Class Designer a quick way to build the basic application or should I just work out on paper and then start coding?
Thanks
As a visualization tool, or for exploratory purposes (drawing up multiple options to see what they look like) it's not bad, but generally I find the object browser does fine for most stuff I care about.
As a code generation tool, it's a terrible idea.
The whole idea that we will design all our code structure first, then fill in the blanks with small bits of implementation is fundamentally broken.
The only time you actually know what the code structure should look like, is if you've done the exact same thing before - however then you can just use your previous code, and you don't need to draw up any new code in any kind of designer.
If you decide ahead of time to use a particular class structure before you've actually tried to solve the problem, there is a 100% chance that you will pick the wrong design, and shoot yourself in the foot.
Short answer: No.
Longer answer: No, not at all. There's a reason it hasn't been updated.
[EDIT] # MrBrutal - Sorry - do you mean to generate code or just represent a design? Because I took your question as to generate code for you.
I guess this is old, but I use it a lot. It could definitely be improved, but I find it extremely useful to be able to visualize my class structure, and to be able to jump to a specific class or method by clicking on it visually.
It's also slightly easier to add classes/interfaces with than the solution explorer, although the new files always end up in the root folder, instead of the same folder as the CD.
The main benefit I find is to be able to see a group of closely related classes at once. I think the best approach might be to have a single CD for each code folder/namespace.
I've used it a couple of times to get some decent looking class diagrams to put in presentations/blogposts etc. But thats about it...
Any suggestions on other simple UML/class diagram tools that is easy to use and create some nice looking diagrams? Must be able to generate diagrams from .NET code.
I have tried it out couple of times, mainly for viewing existing classes.
If it would show all the relationships, it would be more usefull. Now it only shows inheritation.
I find it useful sometimes, more often for documentation afterwards.
It's a new little utility, but I don't think you get the full functionality in VS Pro - I think you need Architect's Edition.
The comments here suggest that few people find the class designer useful.
Amusing to note that Microsoft designed the class designer to be a useful replacement to useless UML (UML diagrams being untrustworthy once they lose synchronisation with source code).
The trouble with class diagrams is that they tell us what we already know.
I only use the class designer to display my existing classes, but I don't use it the other way, e.g., design your classes there then let it generate the code.