A developer that I have engaged to code a system (java) will be providing their testing reports and scripts for our review. Scripts will be JMeter, I am wanting to gain a robust converter to enable these scripts to be used in for functional testing in a Locally Hosted Visual Studio instance running Microsoft 10.
What have people used previously?
Regards, Karen
Performance scripts are not meant for functional testing as they dont have the interaction capabilities with the page objects like click. So, jmeter scripts are not 100% equivalent to functional testing.
If you want to use the jmeter jmx with Visual Studio then you can do it as VS allows to run the jmx. Check the below reference:-
https://learn.microsoft.com/en-us/vsts/test/load-test/get-started-jmeter-test?view=vsts
Hope this helps.
Related
What tools are you using for CRM plugin development?
I used both "Dynamics 365 Developer Toolkit" and "Dynamics 365 Developer Extensions" previously. Unfortunately, The "Dynamics 365 Developer Toolkit" no longer works reliably for me in VS 2019 (yes, I followed the steps to update the vsix file). I looks like Jason Lattimer's has stopped making the "Dynamics 365 Developer Extensions".
Thanks!
Personally I use none, but rely on an Azure DevOps pipeline to deploy everything.
For client side development I heavily use Fiddler 4 with auto responder rules with a local webpack devserver. I am not sure how to improve this process much more.
For serverside Plugins I prefer using ILMerge Build Tasks (check nuget) and separate the IPlugin interface implementation from my code so I can easily write unit tests for that. I do not use testing libraries like EasyRepro or XrmFakeEasy. I don't think they add a big benefit and more or less negate one of the best effects of unit testing. Creating good testable code.
For plugin deployment I currently use spkl by Scott Durrow and it is working fine so far.
For generating early bound classes I use a custom .bat file that actually just calls the CrmSvcUtil.exe with a couple of extra .dll files that helps creating enums instead of optionsets.
I am not a huge fan of toolkits or templates that dictate how you have to write your stuff, because most of them embrace bad programming patterns. For example the XrmToolkit forces you to use a certain folder structure for your clientside scripts to not mess up your crm system and so on.
XrmToolkit is a commercial Dynamics 365/CDS development add-on that is actively maintained and supports Visual Studio 2019.
I have been relying on it for years to assist with generating proxy classes, registering and publishing plugins, publishing web resources on save, etc.
I have no affiliation with XrmToolkit.
You can use Microsoft.net framework with visual studio or visual studio code for implement dynamics 365 plugins and register that in plugin registration tools.
• Write a plugin
• Register a plugin
Now on my project we use TFS as TestCase management tool, issue tracking system and code management. But we want to move to JIRA and Bitbucket. In VisualStudio we have ability to bind TC to automation test and then run test suite with automation test. The question is: Is it possible to bind JIRA test case with automation test(UI tests, API tests used MSTest framework)? Is it possible to run automation test and see if test case pass\failed? Some reports?
Maybe there is possibility to develop some extension for this?
Unfortunately, right now there are no built-in JIRA importer for data from Microsoft Team Foundation Server for Visual Studio.
However, there are complete third party solutions available which might help you between JIRA and TFS such as below:
TFS4JIRA
MS TFS Connector for JIRA
UseTFS
I already have several unitary test written with google test within my solution.
I've just install the "GoogleTest Runner" visual studio extension (2013).
I did not found any user's guide.
Could somesone tell me how to use this extension, please?
Thank you.
Yeah, it took me a while to figure out how to use it as well. The extension integrates with the unit testing facilities that are built-in to visual studio, so when it's enabled you should be able to just click TEST->Run->All tests and it will pick up your test cases automatically.
One of the little hidden details is that the project containing the test cases must be named {something}Test, otherwise the plugin won't know where to look for the test cases.
All of the load tests documentation on MSDN describes a computer (running visual studio) connecting to a test controller, which connects to the test agents. Is it possible to run Visual Studio on the Test Controller, and run tests from there?
Running Visual Studio on a Controller with agents is more or less like running local test. You can run load tests from a single (developer?) machine, but you usually can't generate enough traffic to really see how the application responds, especially if the target is hosted on the same machine. It's also very depending on your context.
Using Controllers & Agents in a test rig, provides a distributed architecture to generate a lot of load and activity.
I realise that there are many older questions addressing the general question of NUnit v MSTest for versions of Visual Studio up to 2008 (such as this one).
Microsoft have a history of getting things right in their 3rd version. For MSTest, that is VS2010.
Have they done so with MSTest? Would you use it in a new project in preference to NUnit?
My specific concerns:
speed
running tests within CruiseControl.NET (either commandline or MSBuild task)
code coverage reports from CC.NET
can you run MSTest tests in debug mode
(We use ReSharper, so test-runners are not an issue for us. We have used NUnit for the last few years. We do not have TFS.)
List item speed is same, but MsTest may be a bit slower because it creates folder for test run every time
MSBuid and CC.Net is big pain. You can't run MSTest on computer without VS on it (not 100 sure about 2010, but with 2008 it is so)
not sure, sorry
yes you can, from visual studio
My recommendation is following: if NUnit satisfies you - use it, forget about MSTest
To correct some old information on the thread;
It IS possible to run 64 bit tests in 2010
From VS2008 forward it is not neccesary to have MSTEST create directories anc opy the binaries in, just disable deployment, in 2010 thats the default but you have to set it in 2008
2010 MSTEST is faster but as its a generalised test framework that also runs load/web/UI tests there are compromises in the design that will lead to it being slower. Jamie Cansdale appears to have managed to get perf increases with the lastest releases of TestDriven.net's support for MSTEST
I've mainly used NUnit, some xUnit and some MSTest. They seem functionality equivalent, but I don't like the MSTest test runner. It runs in visual studio so it either crowds the screen or is on another monitor getting in the way everytime I tab to visual studio. (I run NUnit on another monitor, but it doesn't cover everything on that monitor everytime I focus visual studio). It takes too many clicks to find out what test failed and why.
NUnit can run in the background until a test fails, at which point it shows you information about the breaking test. This seems like the ideal for keeping red/green/refactor going smoothly.
Nope. Same issues regarding appdomains and assembly resolving still exist. I would avoid unless you want the new goodness for other functional testing or integration with Team System.
I don't know much about CruseControl.net, but you can debug tests. We currently don't use TFS either, and the MSTest is working for us.
If you think you'll ever run your tests in 64 bit mode, use NUnit. MsTest is only x86.
One major difference between the two is that MSTest makes a copy of the current DLLs every time it runs a test. If you're doing TDD and running your tests frequently, this can eat up a lot of hard drive space.
If you're using MSTest, you can change this setting in Tools > Options > Test Tools > Test Execution. "Limit number of old Test Results to" is set to 25 by default in Visual Studio 2010. I usually change it to 1.
MSUnit runs your test cases under conditions that are different from the actual execution environment. Specifically, the deployed files differ from those that are deployed when you run your actual project. Nethertheless, there is the [DeploymentItem]-Attribute to specify which files shall be deployed by MSUnit. So if your application depends on any external
files, such as
database files
database configuration file
application configuration file
...
then MSUnit is not the right choice, because the MSUnit tests never cover what your file system is going to look like in execution environment. The Visual Studio Project File settings for deploying files (Copy always, Content, etc.) are ignored by the MSUnit runner. So those settings cannot be tested.