A
A
Alex_Master2015-11-17 16:46:26
Web development
Alex_Master, 2015-11-17 16:46:26

How does the development of web applications work with the pros?

I often encounter the problem of bugs, developers do not always find them themselves. Even after the testers go through the cases, some bugs still pop up that no one noticed.
I now have the following development scheme:
Dev on a separate server, development is underway and the main tests are being carried out by developers.
Pre is a version of the product on production servers and with a production environment, but with a copy of the real database. It conducts pre-release tests of the product by testers.
Prod - production.
Deploy / base migrations / versioning - everything is configured automatically. We do not do it by hand.
One colleague advised me to first write tests, and then write code for them. We have not done this yet, we want to introduce it. Is it really effective?
Tell me how web development works with real professionals? Where can you read about this topic?
I would like to do everything according to Feng Shui, see fewer bugs, work faster and more efficiently :)
I will be glad to help. Thank you.
PS I'm also interested in your opinion about software for version control, development, migration, testing, etc. Which stack is best :)

Answer the question

In order to leave comments, you need to log in

4 answer(s)
S
sim3x, 2015-11-17
@sim3x

One colleague advised me to first write tests, and then write code for them. We have not done this yet, we want to introduce it. Is it really effective?

Yes, less code is written this way :)
Only the sequence looks like this
0. We write a test for the new functionality
1. We start tests = testing should take up to 2 seconds to run
2. We see a new failed test
3. Fix it
But in any case, a ticket is started first in the bug tracker, then it is hung up on itself, then a "git pull" is done, and after that the code is added
. Various dev / prod / test environments should be prepared automatically + should be in the form of ready-made images for virtual machines or for docker.
Sequence: a script is written to build the image, sent to the repository, at night or instantly the machine responsible for the images collects it and the developer can use it.
IMO dev/prod/test should not be different at this stage - all environment modifications should be done by software that is associated with the PL/environment in which you are developing. Let's say you work with a node and you need packages to optimize CSS - npm installbut in production this is not necessary and you do it. npm install --production
But all these troubles do not add development speed - they do not allow you to make a mess on the project and, theoretically, increase the quality of the code

M
Mark, 2015-11-26
@printf

TDD is quite rare in practice, more often code is written at the same time as tests.
We are now fighting bugs like this:
* "first line" - unit tests
* automatic integration tests: emulate a user, crawl with a mouse, press buttons. Several hundreds of the most popular scenarios are checked.
This all happens in CI every commit. The tree should always be "green": if the tests fail, the highest priority task is repair.
Then (before the release) comes:
* manual QA
* dogfeeding: the company uses its own product all the time. Thus, in general, everyone is engaged in manual testing, to one degree or another.

S
Sergey, 2015-11-26
@sergiula

The Test-Driven Development approach really helps you focus on getting things done. From the pros:
- the developer knows the specific criteria for "accepting" the task
- a good practice of test coverage is built .
More details about the approach can be found in the wiki

S
Sergey Rogozhkin, 2015-11-26
@thecoder

There are no spherical "pros" and "non-pros". Each developer is trying to identify and resolve contradictions, trying different techniques. With tests (even written 2 weeks after), you will feel much more comfortable psychologically. Just write tests even with a carcass, even with a scarecrow. But this is a tactic.
More important, I believe, is to provide and support the maximum number of scenarios (use cases) for using the product, and by the simplest means. The main indicator of quality: they fell into the pattern of the user's habitual behavior and made him better. The number of bugs cannot be considered in isolation from the essence of the product.
Removing rare and complex features that 10% of users need can give more quality than all tests.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question