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?
Related
I am learning jHipster. My entity relationship model has projects and files. A project can have zero to many files, and a file always belongs to exactly one project.
project <(1:1)-----(0:*)> file
Users interact with the application similar to using an IDE. First, after opening the initial website they always have to select which project they want to work in. (Of course they can also create new projects, or perhaps delete an old one.) Only then they get access to all resources added to a particular project such as files.
As a consequence, my REST API should logically look like this (to get a single file):
GET /projects/{:projectId}/files/{:fileId}
In the backend, depending on whether fileId is a UUID or not, I might even have a method:
findFileByIdAndProjectId(String fileId, String projectId)
The problem is that jHipster creates all entities in a "flat way". Each entity seems to have its own REST API without nesting, and there is simply a reference to an other entity rather than proper composition. Adapting the generated code is quite a bit of work as it requires lots of changes both on the frontend and the backend, but more importantly, it probably breaks the ability to re-create my code when an entity has changed.
I am curious: What different options do I have, and which one would you guys recommend?
Custom code is the way to go though there are few tricks that can help you:
Using DTOs so you can aggregate entities in service layer
Extending generated classes both in backend and frontend so that you don't change generated code, see excellent talk, slides and code samples from Antonio Goncalves
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
I am having a little problem in my workplace where we have a IIS 6 server where Orchard (1.7) will not run. We are planning an upgrade but that's going to take some time.
Since we are using this site on IIS6 only to run one particular custom module we wrote for Orchard (basically a MVC module with its own Controllers/Actions etc.) I was thinking that a temporary solution could be to rip that module out of Orchard and run it independently.
Of course this extraction needs to take into account how many ties I have with the framework. I was wondering if there is some kind of guide to perform this and if there is something I need to take specially into account.
I am using the Users in Orchard so I would probably have to rewrite some users code. I am also using the Authorizer, which again may mean I need to re-wire something else.
It seems like a daunting job so I am looking for some quick tips on how to proceed if you know any.
Thanks a lot!
It all depends on what components you actually use within your module.
Hard to write any tutorial on this, really.
Regarding Orchard.Users - you could drop all related code usages and rely on the default ASP.NET roles-based authentication/authorization model.
If dependency injection is what you want to keep, then you need to integrate it yourself (for Autofac, but other DI containers will also work). Feel free to copy and change any Orchard components that you use, stripping the unneeded code.
In my opinion the hardest thing to strip out and replace would be any code that relies on content items - hope you don't have it. Rewriting this pieces sounds like an overkill. But if you just use IRepository, going for plain NHibernate or EF instead should be quite easy.
I'd like to share my thoughts about https://github.com/swagger-api/swagger-node-express
It has 564 stars on Github, so I think it is justify to use it, but:
Why should I use methods like addGet/addPost and split my controller by HTTP methods
Why should I involve models to routing?
I can use validators for authentication, but I have to choose some paths, that should be protected there. It duplicates logic, that stores in swagger json file.
Isn't the right way to have a static swagger.json and build Express routes on it?
Or maybe I don't understand some practics
Swagger is just a spec. You could hand craft a swagger spec without any code, serve the spec to a swagger-ui compliant page, and it "will work." You could have a fully defined API and "run" it using the UI pages. Same is true for Express without swagger - you can do a lot of neat things! But some effort would be needed to document the API in swagger.
If you want to use swagger-node-express, you are coupling the code to the API documentation. This can save you a lot of time, and keep changes in the same file, etc. However, like all your questions allude to, you must do things the swagger-node-express way. Faster than doing both separately, but there are constraints one must follow.
There are other swagger packages that tackle this from different angles. I've seen some that try to build the swagger docs from the Express/Restify routes automagically. An alternative to swagger-node-express is swagger-tools, which even includes validation, but I'd guess you'd be limited in some fashion to writing Express without any swagger integrated.
You are free to build swagger docs manually (or with some YAML, jsDoc package or a generator), but that would take some extra time after your routes are written. Plus, it's a separate place to maintain your docs and invariably they will be out of sync at some point, if not abandoned. Using swagger-node-express is primarily a time saver and, even with its drawbacks, that might be worth the extra development effort of the alternatives.
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.