I don't understand how to apply TDD in a project

Question

Database

Good day to all!

For many years now, the company has been trying to start using TDD. We stop all the time for the same reason: a lot of logic is tied to data.

Here is a current example: we are making a system for tracking the expenses of company employees for certain needs. Every month, invoices are uploaded to the website, parsed, information on expenses (who, how much, where) is neatly laid out on several plates. Each employee can go to the page, see their monthly expenses, compare with the limit, get upset when it is exceeded. The boss can view information on all his subordinates, etc. There is an interface for loading new accounts and viewing details of old ones, reports (with export to Excel), admin panel, rights-roles.

It sounds simple in words, but there are not so few bugs and code. How to approach the development of tests? 90% of the functionality relies on data in the database, which needs to be taken somewhere. If anyone has experience with this, please let me know!

Answer 1

Use fake data tailored specifically for the tests. Usually called fixtures.

Answer 2

For unit tests, usually a lot of data is not needed, for the amount that is, mock objects are created with dummy data.

Answer 3

я так понимаю проект уже готов? поэтому применять TDD уже поздно, потому что основной девелопинг уже закончился.
Как бы я поступил:
Вы нашли баг, разобрались в каком компоненте системы он происходит, поняли какие входные данные нужно подсунуть компоненту, чтобы произошле баг, поняли какие данные должны получится на выходе компонента, если бы бага не было, пишете тест:
берете тестовые данные, запускаете на них ваш компонент, смотрите что получилось на выходе.
testData =…
expectedResult =…
result = youtSytemComponent.superProcessor(testData);
if (result == expectedResult) return TestSucces;
else return TestFail;
так постепенно у вас будут накапливаться тесты и вы уже не испортите, то что уже исправляли.
It is not necessary to use a real database, you can write a snag for tests that will pretend to be a database. It is desirable to choose the components of the system as little as possible, for example, a component is usually some kind of class created for specific purposes, you need to check whether it solves them correctly.
not everything can be done with TDD, BDD is also a useful thing.

Answer 4

When I first met TDD, I also had a desire to shove it everywhere.
First of all, you need to understand that TDD is not a panacea and in the conditions of modern projects it has a rather narrow applicability, because it works well only where the business logic is well localized and the code is loosely coupled.
As I understand it, you have:
1) part of the business logic is stored in storage
2) a complex domain model 3) there is a
UI
focus on integration and UI tests.

Answer 5

I'm not sure how useful my post will be, but I want to note that unit tests should cover only public methods, public API, i.e. the code that other components of the system depend on.
For example, there is code that takes something and generates something. Here we test what he correctly accepted and deduced. All accompanying logic can be omitted.
At least that's how we do it.

Answer 6

First, you need to understand what unit tests are. As a rule, if we are talking about classic unit tests within TDD, then these are tests for class methods in complete isolation from the external environment. This means that not only the data from the database cannot be there, but there should not be any calls outside the class at all. Everything gets wet. As a general rule, TDD (if you know how to cook it) speeds up writing code (although you may hear another opinion - but it is not true). And it has a lot of useful side effects, but it is not cheap to maintain (although it pays off due to greater system stability).
Such tests require architectural readiness of the system. For example, your business entities from the base should implement some kind of interface for mocking. Most often, unit tests will not pay off on an already written project.
Understand what you want to achieve. If you need the stability of some certain "evil" program modules, write integration tests.
If you want to achieve system stability in relation to requirements, write system tests that work with the application as a black box. There are many developments in this area within the framework of the BDD approach.
If you don’t have formalized requirements, do it first of all - otherwise no tests will help you.

Answer 7

IMHO - the problem of the complexity of writing tests usually follows from the size of the code being tested.
It is difficult to write tests for a piece in 2 csloc, which, perhaps, does not brew coffee.
If initially the code did not work out and you have legacy, then the tests can be screwed only after refactoring.
You split the logic into small chunks that do little work and cover those chunks with tests.
And now you have a classic problem - you are trying to eat the whole elephant :)
PS. Integration tests are a fragile thing, you can be tormented, especially if there are frequent changes in the code.