What is the difference between TDD/BDD and what kind of modules should be used?

Question

JavaScript

Hello everyone, I'm just starting to study automated testing systems, I settled on mocha + chai + sinon. In general, the logic of work and the construction of test cases are clear.
But there are a few questions that I would like to hear the answer from knowledgeable people.
1. what is the difference between TDD and BDD when which is better to use? (for example, mocha has separate settings for bdd and tdd).
2. Is this type of testing relevant only for functional parts of modules? Or is it the same for the UI?
For example, I work with Meteor + React and 90% of the modules are react components that may include some handler functions, and very rarely additional auxiliary functions. So the question is what to test? should handlers be tested? whether it is necessary to test the correctness of the output of the component in the DOM (although I have no idea how to do this)? Or is it worth testing only the additional functionality of the site that has nothing to do with the UI?
3. Well, I would also like to know what types of modules to test, only containing functionality, or modules that include UI components and handlers, the same?
Thanks in advance for your replies!
For links to additional special thanks to literature and plus)

Answer 1

There are many types of tests
https://events.yandex.ru/lib/talks/535/
*DD - development style, when you first write a test, then it fails, then you write code so that the test passes
B or T, it's up to you to decide , or superiors. It is better to try writing the same thing on both and, based on your experience, choose
BDD - better suited for functional tests
TDD - for unit

for functional parts of modules

oxymoron. Everything that you write performs some function
Test the module, if it is reused, it is worthwhile to
test things critically

should handlers be tested?

https://facebook.github.io/react/docs/test-utils.html

whether it is necessary to test the correctness of the output of the component in the DOM (although I have no idea how to do this)?

it's easier to leave it to manual testing

Or is it worth testing only the additional functionality of the site that is not related to the UI?

such functionality should already be covered by unit tests and functional tests and should show an error before reaching the UI

Answer 2

TDD
- we write tests - a small piece, something that can be written in 10 minutes. At this stage, we formulate what we want to write.
- we write the code - we write the code that makes the tests "green". i.e. everything works. We do it as quickly as possible, in the dumbest way, which is simply the fastest way to do it.
- refactoring - after everything works, or after a couple of iterations, in order to accumulate a little more "dirt", we clean the code one by one. It is important to clean one thing when refactoring. Either code or tests (yes, yes, they also need to be refactored, sometimes eliminating duplication). Corrected the code - ran the tests, everything is fine? Then the tests can be corrected. Well, etc.
BDD
- writing feature specs - this is the stage of detailing higher-level requirements. Features Usually at this stage thoughts are simply written down as what should work. In this regard, the description of the feature describes the use case, and the scripts detail the behavior of the feature. That is, if someone has a question about how something should work, people describe an example in the form of a script. Like what is, what we are doing and what the system should give out as a result.
- writing code - just like in the case of tdd, you can write code for different levels.
- refactoring.
TDD is for a single developer, BDD is for a team. And BDD-style assertions for chai are pathos. In fact, this is "feature planning" within libraries and individual objects. Slightly smaller scale. But it doesn’t differ from TDD at all, although if you try hard, you can also evaluate the value of features for users of our library, etc.
After all, the main idea in BDD is that featurespecs should be able to read the product of the owner or the stakeholders, that is, those who actually need the project, to say whether it should work or not. In the case of libraries... well, you write something for developers, and they are able to read tests as a feature spec. And in principle, not far from the subject area.

Answer 3

I highly recommend this book for understanding the concept of BDD - BDD in action . Written in a fairly easy to understand language, the main ideas can be understood from the 1st chapter.