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 9 years ago.
Improve this question
My Proj Manager asked me to write a BDD.
What should a BDD written for ?
Should we write a BDD for each Story or for each epic ?
Normally (there are, as always, exceptions), you start by writing your user stories in a format that BDD tools can read (a format similar to the Gherkin language). The user stories can then be implemented and executed by the tools as tests.
A programming language neutral intro to BDD can be found at Wikipedia.
BDD is Behavior Driven Development. As a result, you have a specification that can be executed via some testing framework, thus ensuring requirement completion. Each User Story usually has several scenarios. Here is an example from our project:
Given Bug (Task, User Story, Feature) view
When I expand 'Actions' menu
Then I see 'Attach to Request' link above the 'Move and Copy' action
When I click 'Attach to Request' link
then I see requests lookup
[image of the lookup]
It is better to create scenarios that can be automated. It is challenging, but doable. Here is the more complete example of BDD scenarios:
http://www.targetprocess.com/blog/2009/10/bdd-and-user-story-specification-examples.html
Even with simple Given -> When -> Then format you have a good structure for your user stories, so it is worth to use this format without automation. Still automation is a huge benefit that BDD provides.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
how to choose between these two automation tool how Squish is better tool
These tools are simply different and its up to you to decide which suites better your needs & budget:
Appium
open-sourced and it costs nothing.
no support engineers to help you with developing tests and telling how to use Appium in a better way. Its only you to search information in docs and forum, ask questions and spend your own time.
no test recorder, you can simulate similar actions and test locators with appium-desktop, but thats it
requires knowledge of at least 1 programming language (java, python, js, ruby, etc.) to write the tests.
SQUISH
proprietary software with individual licence costing ~7k EUR a year
you can contact support engineers, you already paying for it.
test recorder will help in case you are not familiar with programming
In terms of stability & easy to use it more person & application specific, so I would say: check the points above and made your choice.
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 7 years ago.
Improve this question
I have code completed a project almost 50%, but haven't written any test code. I want to write rspec, capybara tests. Now this is reverse of what actually is done in testing. What should be my strategy here from where should I start (from model, controller, feature) and what should be my approach. Also are there any tutorials for this
Usually it's better to start from feature tests. They are easier to write and they provide most of coverage because cover a lot of functionality at once.
Also you will need not so many feature tests comparing to unit tests, for example. Because they are on top of the Testing Pyramid
When you will achieve decent coverage you can start throwing in unit test and refactor your codebase. Having feature tests you can eliminate the fear of refactoring. As soon as you haven't write test before the code your methods would be probably hard to test without additional refactoring.
That's is an additional advantage of having feature tests before unit tests.
You can find bunch of articles describing how do people usually test their projects.
As an example here is an article from Thoughtbot https://robots.thoughtbot.com/how-we-test-rails-applications
I would also recommend the Working Effectively with Legacy Code book.
It describes how to start covering projects with tests and then refactor the parts.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
The title says it all, if I test using capybara :
visit this page
expect this content
and do this for every single feature(e.g signin, signup, search, clicking all the links and buttons, etc), would that be enough? Why would I need to test controllers and models? If features are working as expected, doesn't that mean everything is working in harmony?
That technique is called black box testing also know as functional testing. If you are testing as if you are a user of the application it is considered black box. If you are testing it from within it is considered glass box testing.
The question of whether or not is it enough is a matter of personal opinion. My opinion is if it is thorough enough then yes it could be enough.
Some of the advantages of black-box testing include:
You have a good chance of writing tests that weren’t imagined by the programmer.
The environment the program is running is also tested
The invested effort can be used multiple times
Some advantages of glass-box testing include:
It forces you to reason carefully about implementation.
Spots the Dead Code or other issues with respect to best programming practices.
Reveals errors in hidden code.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
From what I can tell from online forums and posts, one of the main focuses of BDD/ATDD seems to be on discussion and ensuring that the customer, developers, testers and other relevant parties are involved in the understanding what the system must do.
Question 1: Do BDD/ATDD stories replace the need for traditional requirement specifications, such as the those captured using the Volere Template?
Because the traditional requirement specifications are one of the key inputs for developers and testers, traditional requirement specifications tend to be comprehensive.
Question 2: Should BDD/ATDD stories also be comprehensive enough to allow a system to be fully tested?
Question 1: Instead of looking at this question as a black-and-white situation, we should better understand how these two requirements capture methods get along with each other. Writing a story in the BDD/ATDD methodologies, or in Scrum for example, does not imply removing the templates like volere off the table. If we take a look at the volere requirements specification here, we can see that most of the information regards to project-related issues, and the shell used for functional requirements is far from being different to a story. They just have different information, not exclusive one.
Question 2: Here we have the advantage coming from the methodology itself. BDD comes from TDD, we can more or less rely on the test-first oriented process to allow the team to test the system. But, as I mentioned in question 1, making a BDD/ATDD story more comprehensive is not a sin, and wouldn't compromise the general idea of the story. This would also prove useful when interacting with more experienced clients.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
You can find thousands of questions out there about how you develop software and which methodology is the best one. But mainly these are targeting medium to large teams, with people having different roles and responsibilities.
What I'm interested in is what methodology are you using for your one-man-shows? What steps are you doing, what documents are you creating to get the things you want to develop clear and document it well, to share it with the community?
Especially, I’m interested in the following questions:
_Are you using a structured approach even you’re developing on your own or no at all?
_What phases are you using?
_Which documents are you writing before and after coding?
And if you have “your” standardized approach, can you share templates which you are using?
Thanks in advance,
cheers
Gerry
Personally I think it is a matter of making decisions when it comes to the development process (solo). In my case I wouldn't recommend setting up a massive development process but I would pick elements which prevent problems that I have earlier had. My approach for small applications (in the right order):
Always write down what you are going to make and what you are not going to make (define a scope) - Think of functional requirements (Functional Design)
(OO only) Make a class diagram that displays relations between classes. (Technical Design - Sequence diagrams, while usefull, take up massive amounts of time to make)
Write your program according to what you have just written down (or part of it).
Refactor and redesign your application (once in every X hours, write this one down)
Repeat step 3 to 4 until the result is what you wrote in the Functional Design.
Walk through every corner of your application to find every single path and write this down in a testdocument. Identify possible problems in the paths and test them.
When it comes to big applications however (or assignments for someone else) I prefer using the "medium to large teams" approach. Which almost brings a guarantee that you will not be meeting most problems.