We are looking into coded UI, and since we have C# coding experience we'll be coding up the automated tests ourselves.
I already know that it is possible to have a test case with defined test steps. Each test step is actually a function inside the test method and the description comes from the summary.
This is a great way for the c# coders to expose what they're doing to the non coding testers who will interact with these automated tests using MTM (Microsoft test manager).
However, it would be awesome if the C# coders were able to create generic functions as "Shared Steps" perhaps, and in this way non technical testers were able to assemble new tests in MTM using these building blocks.
Functions such as : Open the settings dialog, Maximize Window, Add an item (with parameters), Close all open tabs, etc.
However these would be coded functions, not from a recording.
The idea would be that once these functions are created and stored in TFS (Again as shared steps), the tester would then be able to use these functions as building blocks for more automated tests.
I also have to stress that these functions will be fully automated, and so new tests assembled in MTM too need to be fully automated without needing to open up Visual Studio.
Is this at all possible?
An approach used by some people is to create a test framework containing many useful functions. The test itself is then written as a data driven Coded UI test, each step being one entry from the data source. (Typically each step might be one line in CSV file.) Some columns of the data source would be commands and others data for those commands.
The commands could be relatively low level such as: find a window, navigate to a page, run an application, find a control in a window, enter text into a field, click a button or a link, verify that a field contains a given string.
Commands could be for higher level activities in your applications, such as: login, fill in a form.
Frameworks can let non coders write tests using terminology they understand. Frameworks are challenging to write.
This isn't really possible in the way you're asking - you will not be able to have your non-technical testers creating automated tests from test manager. A coded UI test will always have to exist as a test in a code file.
All of the details for a test manager test are available through the TFS API, so I suppose it should be possible to create your own layer that could generate coded UI code based on a shared step mapping system, but it would be a fairly major undertaking - its probably easier to have automated tests created by technical people.
Related
Has anyone done test automation for Revit? What tools did you use?
WinappDriver is able to open revit window but is not able to recognise the elements inside it
Your Revit add-in can only run inside a running Revit.exe session, and the Revit API is completely event-driven, and only Revit.exe can raise the corresponding events, so it is a bit tricky to drive it by a unit testing framework. There are several ways to work around this, though. A few of them are discussed by The Building Coder in the topic group on Unit Testing.
What is the appropriate place to provide RestAPI details while using cucumber? i.e. In Feature file or Step Definition file?
The RestAPI is not really part of the business problem you are solving. Rest is not your core functionality. It is just one, technical, way of using the real functionality you are building.
I would therefore not describe a RestAPI in the feature files using Gherkin. I would hide these implementation details in the glue code connecting the examples written in Gherkin with the system under test.
Cucumber is a tool all about communication between groups of people throughout the business you are working with.
If you're working on a project alone, there is less of the need to describe features in business language (although, it is useful for drafting up ideas using a BDD mindset).
My advice, keep the feature files without code, CSS or any other things that could throw off a layperson. Move these to the step definition file instead, and describe what you're doing in terms that a layperson can understand.
You should store it in the step_definitions file. Keep all the coding tagged to the gherkin steps in the feature file to the step_definitons folder inside which you create a file.
Its always better to keep feature files without the code, they are mainly for better understanding of the testing process and business scenarios and best practise when you view it from BDD perspective.
In case your API values are frequently changing, you can also, mention the values in the cucumber gherkin steps, and pass it as an argument to the step_definitions file. So that any change in the values can be handled in the feature file itself, within the "double quotes" instead of going to the code every-time
On a side note, what gem are you using to test on the REST API? Airborne?
I'm trying to build my first app on Hybris, but I'm not sure what is the best approach to build such applications. Let's say I sell flowers in my store. Currently there are 2 ways how to do it:
Create accelerator template and then reconfigure application.
Building app from the beginning.
The first solution may look very attractive, but I don't think it is better solution because:
Hybris doesn't provide an accelerator for my specific solution (flowers), application reconfiguration may take a lot of time.
Some accelerators contain more that one store - other stores should be removed.
The mess in the database. I have to spend time and understand which tables should be removed.
The second approach seems the most logical, but in this case I have some doubts, because the speed of development will be significantly reduced. Moreover, I think that developing a simple store on Spring Boot will be much faster than learning the Hybris platform's extensions and how they work together.
In this case, how should I start develop my application?
Honestly, I don't have experience with building complete SAP Hybris application from the scratch yet, but I have some experience related to development of the SAP Hybris extensions, so I'll try to provide my potential approach because I don't see many answers here.
I'd do it as follows:
Get the whole commerce suite
Run one of the recipe with the installer script (choose one, which will be the best for you - one of the most popular/common recipes is b2c_acc)
Remove unwanted extensions from the localextensions.xml file if necessary
Add another extensions, if you need them
Depending on your use case, create your own extension basing on the one of templates with ant extgen task inside the hybris/bin/platform/ dir (e.g. yacceleratorstorefront, ybackoffice, yempty, etc.)
Add your custom extension (or extensions) to localextensions.xml file
Start your development within your custom extension created out of available template
I know, it's kind of "specific" platform. I hope this answer will help a bit.
Cheers
VS2013 update 5, MVC5 using Areas
I have a stand-alone function programmed for a website. The functionality is a specific user interface to collect survey responses in a particular way. It has several controllers, a model and a group of views. The functionality is completely contained in an Area of the project, except for the Shared _Layout file that provides the main menu for consistency.
'Is it possible for me to' / 'how do I' compile this Area into a single or set of .dll file(s) that I could then add conveniently to other websites? I'm assuming creating something for transfer/download is very standard functionality. For example, I used Elmah.MVC for this site. What I want to do is pretty much create a package that can be downloaded in a similar way to how we integrate Elmah.MVC into a site. (Be certain I'm not talking about creating error logging software, I'm only using Elmah.MVC as an example of software that is easily integrated into other website applications.)
I've never compiled any website functionality into a .dll(s) for use elsewhere and would appreciate either some specific guidance, or perhaps what would be easier is to provide a link with a good step by step tutorial or explanation for how to do this. Most of what I've found on the web describes bits and pieces of doing this, but it's not enough for me to feel confident with it.
It seems to me there are a lot of 'moving parts' to taking a particular piece of an MVC application and turning it into something that is easily added to other projects.
A particular issue I don't quite grasp is the difference in downloaded packages between getting code and getting just the .dll(s). For instance, when I download an MVC5 site, I get controllers, models and views, but when I download Elmah I get a .dll and no code files. Also, I do understand the concept of transforms, but I'm just struggling right now with even getting from my programmed application into a 'package' regardless of the transforms that make it easy to integrate into another website.
These are just some of my questions I have about how to perform this particular process in developing deliverable and/or shareable software.
What you are looking to do is create a portable MVC Area project. A Portable Area is a set of reusable multi page functionality can be dropped into an application to provide rich functionality without having to custom build functionality that is literally the same in every application. An MVC Portable Area is really just a dll that contains the views, controllers, scripts, etc… needed to use in a website that is either a Web Forms website or an MVC website. A developer can use them for a reusable widget or a complete engine. I have actually used them for both. Here is a link with some basic info to get started. http://elegantcode.com/2012/04/06/mvc-portable-areas/
Microsoft Coded UI Test (CUIT). Can I create an independent (external) Visual Studio 2012 Premium or Ultimate solution in C# to record on my application UI without the application's source code? This solution can reference the application's assemblies. The CUIT API does not seem to help. It is not desirable to use Microsoft guidelines in doing CUIT, as it creates and inserts a test project into the application's solution. The development team does not want this test project, created by the QA team, to be part of their source code to check into their source control.
Coded UI testing with Visual Studio is about testing the user interface of an application. Coded UI does not care how the application was constructed (but see Note below). Coded UI test projects do not need to be in the same solution as the application. Coded UI can be used to test websites and web applications (via a web browser) where there is no Visual Studio solution available for the application. Coded UI can also be used as an automation tool, to automate routine operations that use several programs and websites to perform some action. For such automation there would be no single solution file that should have the Coded UI project.
My understanding of Microsoft's Coded UI guidelines is that sometimes it is good to have application and test in the same solution, just to keep them together so as to encourage testers and developers to use the test and keep them up to date. But there is nothing to force such togetherness.
I do not understand the impact of this sentence in the original question: "This solution can reference the application's assemblies."
Note: Coded UI needs the application under test to expose some of its user interface properties via the MSAA or UIA mechanisms. This is done for you with many types of software. See the "Platform Support" section of the "Content Index for Coded UI Test" at http://blogs.msdn.com/b/mathew_aniyan/archive/2010/02/11/content-index-for-coded-ui-test.aspx .
Added 2013-05-02:
The clarification, within the comment, about wanting to link a Coded UI test to the DLLs of an application suggests there may be some confusion between what Coded UI tests are for and what unit tests are for.
Coded UI accesses the user interface of an application much like a screen reader for the visually impaired would. It also moves the mouse pointer, clicks buttons or links and enters text much like the software for people who cannot use a normal keyboard or mouse. Coded UI does not access the code directly so it does not need to reference any DLLs of the application. Before testing your application, I suggest you experiment with writing Coded UI tests to drive the Windows Calculator or to fill in forms on web pages. There are many videos and tutorials on the internet that demonstrate how to use Coded UI. Once you have some understanding of what Coded UI does and how to use it, you should be in a much better position to test your application.