Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
I have to start applying TDD and BDD APPRoach for the first time with the help of my team so I need some clarifications based on your exeperience:
1 - can we share the same feature file for BDD and TDD
if yes what plugin to use for that ? we re going to use karma and jasmine for TDD but we still don't know how to link functions with test scenarios
PS : I DON'T get it when people give -1 whithout even writing a helpful answer !! be useful or stay quiet
BDD and TDD are different. Feature file is a BDD asset and you shouldn't be using that for TDD.
Before starting any development, you start with BDD collaboration and derive scenarios from the requirements as concrete examples by a team’s cross-functional members—mainly the three amigos i.e. Developers, QAs and BA or Product Owner. BDD breaks down the requirement as examples in plain, natural language. The examples explain how the application should work from a customer’s perspective.
Once the team agrees on the scenarios the developer writes code to implement each of those agreed scenarios. When you practice TDD, which you should, the developer either on his own (or with other developers in a pair/mob programming) writes tests for different unit of the functions s(he) implements. Once the tests are written, the developer implements the code for the tests to pass. This approach is called Red, Green, Refactor (RGR). Here is a great article on RGR and how it is done using TDD.
So in summary, you should use both BDD and TDD to improve quality of your product and to reduce time to market. BDD is for the team and helps you derive scenarios which keeps the entire team on the same page and the testing you do at the BDD level is functional testing. Whereas TDD is applied and owned by developers and the test you do at the TDD is unit level (i.e. not functional just checks if the code works as expected and you mock all external interfaces including UI, DB or any external calls). If someone claims Testers/QA should be writing TDD, then they have got TDD completely wrong.
I have also written a very detailed post difference between BDD and TDD in my blog. Here is a link to that article https://blog.nocodebdd.com/bdd-vs-tdd/
We will also be publishing a video about BDD vs TDD in our youtube channel https://www.youtube.com/channel/UCJl6M7o44mGaLX03AP22KTg. There are other videos which explains what BDD is about and how you could roll out in a project which you might find useful
Related
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 5 years ago.
Improve this question
I get the concept of unit testing and TDD on a whole.
However, I'm still a little confused on what exactly unit testing frameworks are. Whenever I read about unit testing, it's usually an explanation of what it is, followed by "oh here are the frameworks for this language, i.e JUnit".
But what does that really mean? Are framework just a sort of testing library that allows programmers to write simpler/efficient unit tests?
Also, what are the benefits of using a framework? As I understand it, unit testing is done on small chunks of code at a time, i.e a method. However, I could individually write a test for a method without using a unit testing framework. Is it maybe for standardization of testing practices?
I'm just very new to testing and unit-testing, clarification on some basic concepts would be great.
A bit of a broad question, but I think there are certain thoughts that could count as as facts for an answer:
When 5, 10, 100, ... people go forward to "work" with the same idea/concept (for example unit testing) then, most likely, certain patterns respectively best practices will evolve. People have ideas, and by trial and error they find out which of those ideas are helpful and which are not.
Then people start to communicate their ideas, and those "commonly used" patterns undergo discussions and get further refined.
And sooner or later, people start thinking "I am doing the same task over and over again; I should write a program for me to do that".
And that is how frameworks come into existence: they are tools to support certain aspects of a specific activity.
Let's give an example: using a framework like JUnit, I can completely focus on writing test cases. I don't need to worry about accumulation of failure statistics; I don't need to worry how to make sure that really all my tests are executed when I want that to happen.
I simply understand how to use the JUnit framework; and I know how to further utilize JUnit test cases in conjunction with build systems such as gradle or maven - in order to have all my unit tests executed automatically; each time I push a commit into my source code management system for example.
Of course you can re-invent the wheel here; and implement all of that yourself. But that is just a waste of time. It is like saying: "I want to move my crop to the market - let's start by building the truck myself". No. You rent or buy a pre-build truck; and you use that to do what you actually want to do (move things around).
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 6 years ago.
Improve this question
A common story
Story: User logging in
As a user
I want to login with my details
So that I can get access to the site
Given such a broad coverage, it is useless if I mock the system components such as DB in order to perform the test, so can I say that people mainly use BDD in integration test?
Here's my terminology.
Scenario: an example of the user using the system, with all relevant components in place rather than mocked out. May be automated and used as an acceptance test, but the conversations between business, testers and devs are the most important aspect of BDD. Often created using the Given / When / Then template, sometimes in tools which allow for natural language capture such as Cucumber or JBehave.
Integration test: Crosses the boundary of two components, and usually used to check the integrity of integration of those components. For instance, may be used to send messages back and forth between the client and server layers of a web interface, or to check database bindings with Hibernate, etc.. Does not necessarily involve the full stack. A scenario could be considered a particular kind of integration test. BDD doesn't really apply for most non-scenario integration tests, though you could still conceivably use the Given / When / Then template.
Unit test: An example of a consuming class using another class, usually with collaborators mocked out. May also be an example of how a consuming class delegates work to its collaborators. That's how we talk about it in BDD, anyway (you can do BDD at both levels). Can also use the Given / When / Then syntax.
Story: A slice through a feature to allow us to get faster feedback. The behavior of a feature may be illustrated with several scenarios, and these can also be used to help slice up the feature. Often illustrated with the As a... I want... So that... template, or the In order to... as a... I want... template of Feature Injection.
Feature: Features represent the way in which users will use the capabilities we’re giving them. This is the stage in which we start defining the concrete implementation and UI. A feature may be a web page, part of a web page, a module in a windows UI, part of an app, etc.
Capability: Something a user can achieve with the system, or which the system can achieve. Ie: A user can book a trade, the system is secure enough to withstand hackers. Phrasing scenarios at this level helps them be independent of the UI and keeps them in the language of the business.
Hope this helps.
Your example is a user story, which describes acceptance test. Acceptance tests could have end-to-end scope, but not necessarily. Core difference between acceptance and integration tests, is what they are focused on. Acceptance test is business-focused and could be written/read by non-technical person (customer). On the other hand we have development-focused integration tests, which simply verify that two or more components could work together.
Back to BDD. It could be used in acceptance testing (feature level) and unit testing (code level). There are even different tools for different levels of BDD:
SpecFlow (acceptance testing)
NSpec, NBehave (unit testing)
Behaviour Driven Development is thinking about the behaviour of a product in a given scenario. It extends both Test Driven Development and Domain Driven Design. Also BDD is thinking beyond integration test. BDD is about maximizing the communication between the Users, Developers, Testers, Managers and Analysts.
Integration Testing is considered as a step of BDD. Integration testing can also exist out of the context of BDD. As integration testing can be used to cover high-level behaviour of your application without dropping into the unit testing.
Behaviour is about the interactions between components of the system and so the use of mocking is fundamental to advanced TDD. Expertise in TDD begins to dawn at the point where the developer realizes that TDD is about defining behaviour rather than testing.
A user story may have a broad scope, as it is always a priority of developing human friendly software. It combines the pragmatic approach of Extreme Programming with Enough Up Front Thinking based on Macro Level Analysis to enable Macro Level Planning.
Integration Testing is what we are using BDD for mainly - UI tests with Selenium. Although actually we are not mocking anything with these tests as the BDD Scenarios are used to drive SpecFlow to in turn drive Selenium Webdriver to perform user-journeys such as logging in, clicking menu links, creating records. In fact I'm trying my hardest to do everything through the UI where possible.
I have been working towards and with the Business Analysts to write their user stories in a BDD fashion (in fact it is now in our contract with clients) and it has been very refreshing and useful to find that during the writing of stories in a BDD fashion, we discover edge-cases that might not otherwise have been thought when we extrapolate the requirements into atomic steps (Given, When, Then). It truly is a win-win scenario for both the business and the developers' perspective when we have a more common language to express requirements.
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 6 years ago.
Improve this question
I'm in a project where we don't do TDD, because our bosses and the cliente are very "old styled" people. Because I can't do design through TDD but I feel fear to changes, I would like to write unit tests for my own safety. But, how those unit test would be? Do I have to write a test for each method specification for test that they do what it's supposed they do? Do I have to test for each new functionality like TDD but without design? I have a mess in my mind.
Thanks in advance.
You probably can't hurt anything by doing unit tests - regardless of how well they're done - except for one possible side-effect, and that is false confidence.
We tend not to do hardcore TDD, nevertheless the unit test coverage ranges from non-existent to moderate depending on project, and is becoming increasingly valuable as the idea settles in.
For general pointers, I'd say the following are key priorities for you right now:
Test what you know to be important
Test what you know to be fragile
Write tests to expose any new bugs, then solve the bug by making modifications that pass the test
Apply TDD where possible to any new features
Acknowledge that you can't TDD an existing project. By its nature, TDD only applies to new ground, whether that's a new product, or a new feature for a legacy product. Don't let this fact dishearten you.
Yes. TDD is yet another software development technique which happens to utilize unit testing heavily. Unit testing as a process is fine on its own without TDD behind. Not to mention, sometimes it's not even possible to do TDD yet you do write tests (think legacy systems/existing untested code testing).
But as for what you should test. Depending how deep with testing you want (can) go, you can start with end user oriented functionality, through system components testing (ie. class contracts) up to simply assuring your code does what you claim it does - that's pretty much the final, most fine-grained unit test which you'll most likely have a lot of.
In general, what to test is not an easy question, I've happened to answer several variants of that question already, to give you few tips:
test what your code does, not what it does not
if you got certain requirement, have a test covering it
test single feature at time
focus on public contract, skip private bits
Also, reading few of the top voted unit testing questions might give you some ideas on why you will benefit from testing, regardless of using TDD or not.
When you say "we don't do TDD", do you mean that others don't practise TDD or that your bosses forbid you from practising TDD? If it's the first one, then you can practise TDD as much as you want, as long as you don't try to force other people to do it. If it's the other one, then tell your bosses that they pay you to write code the best way you know how, and TDD is part of how you do that.
You can certainly write tests without practising TDD. People do it all the time. Use the old saying, "Test until fear turns to boredom". Write tests for whatever you fear might not work correctly.
I've recently watched Integration Tests are a Scam by J. B. Rainsberger and am now looking for more material on the subject. I have to say, I'm shocked by how much we're doing wrong, (i.e. integration testing when we should unit test), intrigued by the concepts described by Rainsberger but also confused about how to apply them. I would like to have more of the described collaboration tests and contract tests but I don't know where to start.
The only things that got stuck in my mind are the 4 questions the tests need to ask:
Side A:
Do I ask the right question?
Can I deal with the answer?
Side B:
Can I answer a question?
Do I answer correctly?
But how do I apply this to some random method in my application stack?
Is there a book or a tutorial or example out there that takes a real world example and applies these ideas of isolated micro tests?
Ideally the example uses Java, C# or C++.
Any literature that deals with these concepts in general and helps me understand them better would be appreciated.
Also if there are forums out there where I can ask more detailed questions about how to go about correctly unit testing and maybe even refactoring existing code and post examples would be nice.
Thanks!
I would recommend xUnitTestPatterns - Refactoring Test Code by Gerald Meszaros which provides some insights into your questions and a lot of detail on good and bad of various practices when testing at the individual method level.
If you have read Refactoring by Fowler, you'll see that the answer to your questions is not necessarily black and white, but based on heuristics from your and others experience.
Rainsberger over-exaggerates how inefficient integration testing is, to prove his point in reaching ultimate 100% quality (basic correctness) in code
DbC is focused on formalizing responsibilities and benefits outside of both A and B parties. Is like an extension of interface. So main focus becomes contract itself, a layer in the middle that would tell both parties if they can interact with one another.
Rainsberger clearly says that so far there is no explicit library or language support and achieve both A mocks and B inputs to ask same thing, hinting that it could be a PhD work for someone.
However Jim Weirich has a nice example where contract is a OO-pattern for testing and for both parties that agree to use it
https://www.youtube.com/watch?v=7Yw744FMqTY
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 2 years ago.
Improve this question
Test Driven Development has been the rage in the .NET community for the last few years. Recently, I have heard grumblings in the ALT.NET community about BDD. What is it? What makes it different from TDD?
I understand BDD to be more about specification than testing. It is linked to Domain Driven Design (don't you love these *DD acronyms?).
It is linked with a certain way to write user stories, including high-level tests. An example by Tom ten Thij:
Story: User logging in
As a user
I want to login with my details
So that I can get access to the site
Scenario: User uses wrong password
Given a username 'jdoe'
And a password 'letmein'
When the user logs in with username and password
Then the login form should be shown again
(In his article, Tom goes on to directly execute this test specification in Ruby.)
The pope of BDD is Dan North. You'll find a great introduction in his Introducing BDD article.
You will find a comparison of BDD and TDD in this video. Also an opinion about BDD as "TDD done right" by Jeremy D. Miller
March 25, 2013 update
The video above has been missing for a while. Here is a recent one by Llewellyn Falco, BDD vs TDD (explained). I find his explanation clear and to the point.
To me primary difference between BDD and TDD is focus and wording. And words are important for communicating your intent.
TDD directs focus on testing. And since in "old waterfall world" tests come after implementation, then this mindset leads to wrong understanding and behaviour.
BDD directs focus on behaviour and specification, and so waterfall minds are distracted. So BDD is more easily understood as design practice and not as testing practice.
There seem to be two types of BDD.
The first is the original style that Dan North discusses and which caused the creation of the xBehave style frameworks. To me this style is primarily applicable for acceptance testing or specifications against domain objects.
The second style is what Dave Astels popularised and which, to me, is a new form of TDD which has some serious benefits. It focuses on behavior rather than testing and also small test classes, trying to get to the point where you basically have one line per specification (test) method. This style suits all levels of testing and can be done using any existing unit testing framework though newer frameworks (xSpec style) help focus one the behavior rather than testing.
There is also a BDD group which you might find useful:
http://groups.google.com/group/behaviordrivendevelopment/
Test-Driven Development is a test-first software development methodology, which means that it requires writing test code before writing the actual code that will be tested. In Kent Beck’s words:
The style here is to write a few lines of code, then a test that
should run, or even better, to write a test that won't run, then write
the code that will make it run.
After figuring out how to write one small piece of code, now, instead of just coding on, we want to get immediate feedback and practice "code a little, test a little, code a little, test a little." So we immediately write a test for it.
So TDD is a low-level, technical methodology that programmers use to produce clean code that works.
Behaviour-Driven Development is a methodology that was created based on TDD, but evolved into a process that doesn’t concern only programmers and testers, but instead deals with the entire team and all important stakeholders, technical and non-technical. BDD started out of a few simple questions that TDD doesn’t answer well: how much tests should I write? What should I actually test—and what shouldn’t I? Which of the tests I write will be in fact important to the business or to the overall quality of the product, and which are just my over-engineering?
As you can see, such questions require collaboration between technology and business. Business stakeholders and domain experts often can tell engineers what kind of tests sound like they would be useful—but only if the tests are high-level tests that deal with important business aspects. BDD calls such business-like tests “examples,” as in “tell me an example of how this feature should behave correctly,” and reserves the word “test” for low-level, technical checks such as data validation or testing API integrations. The important part is that while tests can only be created by programmers and testers, examples can be collected and analysed by the entire delivery team—by designers, analysts, and so on.
In a sentence, one of the best definitions of BDD I have found so far is that BDD is about “having conversations with domain experts and using examples to gain a shared understanding of the desired behaviour and discover unknowns.” The discovery part is very important. As the delivery team collects more examples, they start to understand the business domain more and more and thus they reduce their uncertainty about some aspects of the product they have to deal with. As uncertainty decreases, creativity and autonomy of the delivery team increase. For instance, they can now start suggesting their own examples that the business users didn’t think were possible because of their lack of tech expertise.
Now, having conversations with the business and domain experts sounds great, but we all know how that often ends up in practice. I started my journey with tech as a programmer. As programmers, we are taught to write code—algorithms, design patterns, abstractions. Or, if you are a designer, you are taught to design—organize information and create beautiful interfaces. But when we get our entry-level jobs, our employers expect us to "deliver value to the clients." And among those clients can be, for example... a bank. But I could know next to nothing about banking—except how to efficiently decrease my account balance. So I would have to somehow translate what is expected of me into code... I would have to build a bridge between banking and my technical expertise if I want to deliver any value. BDD helps me build such a bridge on a stable foundation of fluid communication between the delivery team and the domain experts.
Learn more
If you want to read more about BDD, I wrote a book on the subject. “Writing Great Specifications” explores the art of analysing requirements and will help you learn how to build a great BDD process and use examples as a core part of that process. The book talks about the ubiquitous language, collecting examples, and creating so-called executable specifications (automated tests) out of the examples—techniques that help BDD teams deliver great software on time and on budget.
If you are interested in buying “Writing Great Specifications,” you can save 39% with the promo code 39nicieja2 :)
I have experimented a little with the BDD approach and my premature conclusion is that BDD is well suited to use case implementation, but not on the underlying details. TDD still rock on that level.
BDD is also used as a communication tool. The goal is to write executable specifications which can be understood by the domain experts.
With my latest knowledge in BDD when compared to TDD, BDD focuses on specifying what will happen next, whereas TDD focuses on setting up a set of conditions and then looking at the output.
Behaviour Driven Development seems to focus more on the interaction and communication between Developers and also between Developers and testers.
The Wikipedia Article has an explanation:
Behavior-driven development
Not practicing BDD myself though.
Consider the primary benefit of TDD to be design. It should be called Test Driven Design. BDD is a subset of TDD, call it Behaviour Driven Design.
Now consider a popular implementation of TDD - Unit Testing. The Units in Unit Testing are typically one bit of logic that is the smallest unit of work you can make.
When you put those Units together in a functional way to describe the desired Behaviour to the machines, you need to understand the Behaviour you are describing to the machine. Behaviour Driven Design focuses on verifying the implementers' understanding of the Use Cases/Requirements/Whatever and verifies the implementation of each feature. BDD and TDD in general serves the important purpose of informing design and the second purpose of verifying the correctness of the implementation especially when it changes. BDD done right involves biz and dev (and qa), whereas Unit Testing (possibly incorrectly viewed as TDD rather than one type of TDD) is typically done in the dev silo.
I would add that BDD tests serve as living requirements.
It seems to me that BDD is a broader scope. It almost implies TDD is used, that BDD is the encompassing methodology that gathers the information and requirements for using, among other things, TDD practices to ensure rapid feedback.
In short there is major difference between TDD and BDD
In TDD we are majorly focused on Test data
In BDD our main focus is on behavior of the project so that any non - programming person can understand the line of code on the behalf of the title of that method
There is no difference between TDD and BDD. except you can read your tests better, and you can use them as requirements. If you write your requirements with the same words as you write BDD tests then you can come from your client with some of your tests defined ready to write code.
Here's the quick snapshot:
TDD is just the process of testing code before writing it!
DDD is the process of being informed about the Domain before each cycle of touching code!
BDD is an implementation of TDD which brings in some aspects of DDD!