I'd like to perform my tests using Cucumber + Excel to store my data. I don't want to keep my data stored on the procedure files. Is there a way to do this?
Yes, this is possible.
What you need to do is to implement reading the data in your step implementations.
If you are using the data from Excel to setup the system under test, then read in the steps that prepare the system.
If you are using steps for verifying the outcome, then read the Excel files in the steps you execute from your then steps.
There, at least, is one possible issue with doing it like this. It may not be easy to validate your scenarios by reading the feature file since the scenarios depend on data that may be hard to read at the same time. So while it may seem like a great idea to combine cucumber and Excel, it may not be so great.
Cucumber is a tool for automating BDD. At the core of BDD is communication between devs, tester and business people. The feature files are used for communication by describing, easy to understand and agree upon, examples. These examples might be obfuscated using the Cucumber + Excel approach.
This is a route I personally would avoid.
Related
I would like to know if it is possible to have an excel spreadsheet that contains Gherkin statements and then convert it to a cucumber feature file. I have looked extensively on the internet and I have not been able to find anything related to this. I did find some forums where it is mentioned that this may not be possible. I am pretty new to cucumber and I would like to know whether it can be done. I also found that with spec-flow (cucumber for .NET) it is possible. But I am using cucumber with Java.
I would appreciate it if someone can give me some guidance regarding this.
Thank you
I haven't seen any tool that support this.
To me, it sounds like you would need a pre-process that extracts the scenarios from their storage in an Excel file.
The answer to your question, "is it possible to have an excel spreadsheet that contains Gherkin statements and then convert it to a cucumber feature file" is yes. But I am not aware of any tool. You probably have to write it yourself.
We have done one implementation where we extracted all the scenarios from JIRA tool. The scenarios were the acceptance criteria and then copied same in Feature file.
To answer your question, we have not done so far, but you may need to write a separate code for same.
I'm new to cucumber as a testing suite. I notice that as I build out feature and write steps. Lets say as a bad example (since I'm working backwards) I write a bunch of stuff for creating posts that require a User.
I end up writing a bunch of User based steps (log in process etc) in a feature set mainly dedicated to Post features.
Is it best practice to later move steps into the appropriate feature set as tests get more complicated and features get added?
You have two parts to consider here.
Organize scenarios so they make sense. That is to place them in the proper feature files.
Organize the implementation of the steps so they make sense. That is, implement the steps in the proper source code files.
Your question boils down to "What makes sense in my context?".
It depends on your stakeholders, do they want all user facing scenarios in the same feature file or are they more interested in business facing scenarios that sometimes involve users? Organize the scenarios so your stakeholders are happy.
How should you organize the steps then? It depends on your developers and your ability to share state between step definitions that are implemented in different source code files.
My approach would probably be to start out small and let the suite grow. This would initially not involve sharing state between different classes during runtime. When the suite feels to large to handle, divide it in two parts that are as coherent as you can make them. When this gets to large, repeat the division again. You will, hopefully, end up with something that works well in your context.
Remember that your context and your product is unique. It probably deserves a unique solution that your team feel they can maintain.
Understandability and therefore manintainability is the most important property I can think of regarding the executable specification you are building.
From a performance/maintenance point of view, is it better to write my custom modules with netsuite all as one big JS, or multiple segmented script files.
If you compare it with a server side javascript language, say - Node.js the most popular, every module is written into separate file.
I generally take the approach of Object oriented javascript and put each class in a separate file which helps to organise the code.
One of the approach you can take is in development keep separate files and finally merge all files using js minifier tool like Google closure compiler when you deploy your code for production usage which can give you best of both worlds, if you are really bothered about every nano/mini seconds of performance.
If you see SuiteScript 2.0 architecture, it encourages module architecture which is easier to manage as load only those modules that you need, and it is easier to maintain multiple code files i.e. one per module considering future enhancements, bug fixes and code reuse.
Performance can never be judge by the line count of your module. We generally maintain modules for maintaining the readability and simplicity of the code. It is a good practice to put all generic functionalities in to an Utility script and use it as a library across all the modules. Again it depends on your code logic and programming style. So if you want to create multiple segments of your js file for more readability I dont think its a bad idea.
I am working on a BDD web development and testing project with other team members.
On top we write feature files in gherkin and run cucumber to generate step functions. At bottom we write Selenium page models and action libraries scripts. The rest is just fill in the step functions with Selenium script and finally run cucumber cases.
Sounds simple enough.
The problem comes starting when we write feature files.
Problem 1: Our client's requirement keeps changing every week as the project proceed, in terms of removing old ones and adding new ones.
Problem 2: On top of that, for some features, detailed steps keep changing too.
The problem gets really bad if we try to generate updated step functions based on updated feature file every day. There are quite some housecleaning to do to keep step functions and feature files in sync.
To deal with problem 2, I remembered that one basic rule in writing gherkin feature file is to use business domain language as much as possible. So I tried to persuade the BA to write the feature file a little more vague, and do not include too many UI specific steps in it, so that we need not to modify feature files/step functions often. But she hesitate 'cause the client's requirement document include details and she just try to follow.
To deal with problem 1, I have no solution.
So my question is:
Is there a good way to write feature file so that it's less impacted by client's requirement change? Can we write it vague to omit some details that may change (this way at least we can stabilize the step function prototype), and if so, how far can we go?
When is a good time to generate the step definitions and filling in the content? From the beginning, or wait until the features stabilize a little? How often should we do it if the feature keep changing? And is there a convenient way to clean the outdated step functions?
Any thoughts are appreciated.
Thanks,
If your client has specific UI requirements for which you are contracted to provide automated tests, then you ought to be writing those using actual test automation tools. Cucumber is not a test automation tool. If you attempt to use it as such, you are simply causing yourself a lot of pain for naught.
If, however, you are only contracted to validate that your application complies with the business rules provided by your client, during frequent and focused discovery sessions with them, then Cucumber may be able to help you.
In either case, you are going to ultimately fail, if there's no real collaboration with your client. If they're regularly throwing new business rules, or new business requirements over a transome through which you have limited or no visibility, then you are in a no-win situation.
I'm trying to decide on a GTD app. Does anyone know of one that automatically syncs with Trac or, better yet, FogBugz?
My suspicion is that none does. Which leaves me with writing a script that does it for me.
Things stores its data in XML, but the contents of the tags are all binary, which makes writing a script nigh impossible.
OmniFocus stores its data in XML, and the contents are literal text. Plugin or script is possible.
The Hit List stores its data in a sqlite3 database. Possibly easier than XML, but I'm not sure yet. The downside is that THL doesn't support recurring tasks, which makes it less useful as a GTD app.
Has anyone tried this? Have I missed an obvious app?
ThinkingRock - Java application, XML data format with plain text, supports recurring tasks. No automatic integration built yet that I know of, but another possible option to script for.
Tomboy has some level of Bugzilla integration but nothing complex. Alternatively it would be fairly trivial to sync something plaintext based such as Vimoutliner (IMO: possibly the best GTD application ever) or Taskpaper.
Probably in terms of easiness it would go:
plaintext > XML > Database > Binary format X
You could just use wget and/or a simple perl script to download the tasks then run a few regular expressions to get it formatted correctly e.g.
<li> ... </li> -> [ ] ...
or in code:
s!<li>(.*)</li>![ ] $1!g
Why not use the task features of the bug tracking systems you're looking at as your GTD tool? Also have you looked at (task coach)[http://en.wikipedia.org/wiki/Task_Coach] It stores all its info in XML.