We are about to embark on a greenfield development using Go for the API tier and would like to use something like Cucumber or Gherkin to develop the specifications along with non-technical stakeholders.
What are our options here in terms of tooling?
This is really too broad of a question and may get closed.
But... A little Googling is all you have to do:
https://golanglibs.com/top?q=bdd
Disclaimer: my BDD package is 9th on that list:
https://github.com/eduncan911/mspec
It doesn't take much to implement your own BDD workflow.
And now with Go 1.7 on the horizon (beta), there are now SubTests that further allow you to encapsulate BDD style contxt grouping and writing with no "package" needed.
Related
We are looking at cucumber for our automation test framework because everyone including business people can understand it.
We use Angualr JS frontend and Java REST backend. Our team that is going to write the step definitions likes Ruby so we want to stick with Ruby for that.
Also we would like to use Maven to tie this process into our build process.
Will cucumber be a good fit given that story above ?
Hui Peztherez, from my prospective cucumber is a great choice, using it with the same architecture expect for Angular.
We are using Maven too, and it's so useful to orchestrate them with Jenkins, using maven to run the tags..
mvn test -Dcucumber.options="--tags #smoke"
ref: https://cucumber.io/docs/reference/jvm
Also Jenkins have several plugin to report the Cucumber Analysis, so useful for testers, and in the end, we are now working about the HPQ server integration with a plugin called Bumblebee (this part is still under development for both sides, our and bumblebee)
Another good choice is Ruby, you can take the step definition so easily defined with Ruby...
We also have a integration with Selenium for the front end side, and it works as well...
So go further!
We are using Cucumber in Java with gradle in past, It was in Maven and It works fine. We have framework for UI and API, In UI we used WebDriver to write step definition and In API, We used RestAssured to write step definition. You can do same thing in Java what you can do in Ruby.
Maven for Java Cucumber :
http://mvnrepository.com/artifact/info.cukes/cucumber-java/1.2.4 - Please add other dependency as per requirement.
Jenkin Plugin : https://wiki.jenkins-ci.org/display/JENKINS/Cucumber+Reports+Plugin
Will cucumber be a good fit given that story above ?
- Yes It is good fit. I will request you to show POC(Proof of concept) to management. I had experience in past that management have no clue about BDD and they have very hard to time to understand coverage. We did very deep dive to provide all information to them. It is very important to answer following question to management
BDD report is providing accurate test converage idea to management ?
Everyone in team is able to write feature file and able to provide same quality of feature file
Feature file and BDD report will be starting tool for check test converage
Thank you.
Please be aware that Cucumber is a BDD framework that can be used on top of a browser automation framework like Selenium WebDriver/Watir/Protractor they are two distinct things. Most of them implements Selenium WebDriver's protocol.
My only concern is for you using Maven in that project setup, I know that you can run ruby code in a JVM by using JRuby. But I'm not sure which plugin you'd use to trigger that from Maven.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
SpecFlow/BDD for Unit Tests?
Over the last few years I have worked in TDD using NUnit/Moq and over the last few months I have been getting to grips with BDD using mSpec.
So far so good but we now want to move more into acceptance criteria based tests where the business analysts are involved and we get an outside in development process.
So now we have predefined Gherkin syntax files and with specflow it feels the right way to work.
However, at a unit test level having predefined Gherkin files would go against what I understand about TDD. In other words, you design as you go a long evolving your design with behaviour.
As we are working using the outside in approach, now at unit test level could it be that we now have the specifications/behaviors that can now be used to drive my unit tests (just feels like it is against the way I have been doing TDD)?
Earlier these files were important for acceptance tests but as a developer I will work alone so they are not necessary unless I use SpecFlow.
Also what benefit would we have at a unit test level having GWT files maintained when we are using mspec? Developers should be able to just jump into the code and read the tests or just run the test runner to see what it is doing.
TIA
JD
My spontaneous answer is No.
Tha main benefit of BDD and tools like specflow and Cucumber is communication with the stakeholders of the project and creating a shared understanding of what is to be built.
The main benefit of TDD is to take small steps through a solutions implementation, ensuring that you build maintainable and great code.
Or if you want; BDD is about ensuring that we're building the right thing, TDD is about ensuring that we're building it right.
I answered a question like this the other day on my blog, if you want more details; http://www.marcusoft.net/2011/11/bdd-and-technical-scenarios.html
I am getting ready to embark on a project mainly for experimenting with languages, but also with a hint of usefulness. It will consist of a server-application, written in Erlang, and client-libraries in a number of languages. Initially I will want to write clients in Java, Ruby and Python. The actual protocol for communication will be Thrift.
I'm looking for a build system that will allow me to build the server and all the client libraries in one go, running unit-tests in each language, then packaging up a releasable artifact of some sort in whatever way is the "standard" for each language.
That means a Jar for Java, a RubyGem and a distribute/setuptools tarball for Python. Erlang probably has something too, but I'm not yet familiar with that. It should also be able to run the Thrift compiler to generate the various Thrift-stubs in each language.
On the pad at the start is Maven. I'm fairly certain Maven can do all I need, but I fear it's too Java-centric, and leaves me with a ton of work for every new language I need to add.
well one should know what the requirements are for every language to create a deliverable artifact.
if copy files from here to there and zip it is enough maven could cover most of the scripting languages.
But you may end up writing plug-ins to support a custom packaging (which is not that complicated, so if there is no build system that may be a good choice).
It might not suit the build systems for every language to force maven upon them. So Maybe use the specific build tools available and wrap them in simple script and execute them using a continuous integration server (like bamboo, jenkings/hudson, teamcity, ...) to have them build in a specific order (to 'fake' dependencies)?
I'm not aware of a cross language system.
Gradle might be more flexible as its approach is more script oriented.
And there is http://eclipse.org/buckminster/ - just for completeness (havent had a look for quite some time)
regards
werner
"It will consist of a server-application, written in Erlang,
and client-libraries in a number of languages.
Initially I will want to write clients in Java, Ruby and Python. "
Maven is good if you follow its way. It is actually more of my way or high way.
See: http://community.jboss.org/wiki/MavenVsGradle
For a lot of standard java projects it is actually very good. But if you need to use other things it becomes fairly complicated very quickly.
From your description it is on its way to become complicated very quickly.
I suggest to look gant (groovy + ant) and gradle. You can call other scripts from gant and/or gradle. JPython, JRuby will be your friend. Ant has a lot of tasks which will be very useful.
I have successfully implemented complicated Java/C++/C build project using Gant. Groovy scripting is powerful and easy to use. Gradle is similar and in some ways more powerful than gant.
I have a system thats highly reliant on various web APIs. I would like to run my API specific tests at least once per day to make sure all API's are still playing nicely and alive. I have a set of unit tests (just plain rb files that test API calls for expected data) and would like to run these every 24 hours. If something breaks, I would like to take an action (e.g. email or sms me).
How best to setup automated Ruby tests and parse the result? Can I just setup a cron job to handle the .rb files? How would I take an action and detect programmatically if the tests are failing? Maybe there is some kind of continuous integration solution for RUby that can handle this?
I've just gone through the process of setting up Hudson CI as my integration server, using this amazing tutorial from Dr. Nic. It installs through a gem, coming pretty much preconfigured, and was extremely simple to get working.
I'm using rspec and cucumber, and Hudson runs all tests when it sees a new commit on my git repository. If all tests pass, it merges the code into my master branch. If any test fails, it holds its horses and sends me an email.
EDIT:
I also want to give ten thumbs up to the ChuckNorris plugin for Hudson. Agile doesn't get better than pair programming with Walker, Texas Ranger.
Ruby has Test::Unit built-in, RSpec, ZenTest, shoulda, cucumber and probably many more tools to help test. Being built-in, Test::Unit is used a lot and is the target to be beaten by the other tools.
ZenTest and RSpec can do continuous testing: You make a change and save a file and they'll see it and run the test suite. I like that because then I know the state of things right away.
I haven't used cucumber, but have used the rest. I heard cucumber's emphasis is on integration testing but that might have been the commenter's feelings rather than by design of the developers. The list of tutorials for cucumber is interesting browsing. In particular there's webrat: Automated Acceptance Testing with RSpec or Cucumber.
Any of these could be wired up with cron to run periodically; Just treat them as you would any other set of command-line apps.
It should be easy to tie in web-testing too, but you'll have to identify the gems/modules needed and write the glue code. I haven't had need for such a beast as I'd go at it using Mechanize and/or one of the other HTTP gems plus Nokogiri to ransack the pages.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I'd be leading a new project soon. And I've been pondering over what are the basic infrastructure for a software project. These are the stuff that I think every project should have:
-Coding style conventions
-Naming conventions
-Standard project directory structure(eg maven standard dir layout, etc)
-Project management and issue tracking(eg trac, redmine, etc)
-Continuous Integration server(eg, hudson, cruise control, etc)
I'm not sure if I missed out anything. Would anyone like to add?
As a preliminary answer, check out the Joel test:
http://www.joelonsoftware.com/articles/fog0000000043.html
Just an appetizer:
Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?
revision control system (eg. subversion, cvs, git)
In addition to yours I will put:
Unit Test Strategy
Integration Test Strategy
Defined Process
Release (delivery) strategy (like milestones, working packages and so on)
Source control branching strategy
What about documentation - how (comments in code, high-level specs), when, amount, who
How you will test - unit/acceptance/user testing
code versioning, some SVN/Git (or is it included in trac?)
team roles and responsibilities - need to be done in ocntext of your project
Knowledge management is crucial. As you already plan to use wiki (like Trac or Redmine) you could use it for KM as well.
Functional testing is a mandatory part of any project. Unit testing is great and it works well for Agile projects but the functional testing is still necessary. You need at least a basic Test Plan. If you plan to have multiple projects or sub-projects a Test Strategy document or Wiki page would be good.
Test Cases, Acceptance Test Cases etc could be driven by your User Stories or their equivalents but they still have to exist in some form.
I would throw a file sharing server into the mix too. I thought version control was so basic, that I didn't even bother to put it there in the list. But its a good point version control.
Configuration Management Plan. You need to have a documented approach to your development workstreams, how you will be merging between then, etc.