[ix-hispana]

I work at a small company. We have 6 javascript developers. All our web projects are node, typescript, and the front end stuff the client wants us to use (though we default to angular). We enforce types for communication with node, so at least you know the structure of all the json going through the network. On the node side we use loopback, which generates a nice site to call the API from outside the project.

We write no tests whatsoever. This is a business decision.

There's a test team of 2 people whose job is to go through our crap (i.e., the user stories) and write docs.

Management has to adapt to clients. Managers use the agile words, but the client's budgeting procedure has to take precedence. Regarding estimations, there's no analyst estimating features and tasks, the developers do it themselves. Developers also talk directly to clients often and go on-site.

Since we're so small (about 30 in total), things are personal. We know everyone personally and can make out who wrote a given piece of code. I think communication must be easier with fewer people. I can't imagine having 500 people committing into my project!

[gubsz]

I always question the 'business decision' to not write tests. How did management justify this point to the developers? Was there any push back?

I ask because our business team has a similar stance on developers writing tests (i.e. it's not worth the effort).

[jrowley]

I think it comes down to the complexity/size of the project, the amount of turn over in the team (with higher turn over you're using going to want more tests and docs), and overall willingness to invest in the product health. Some teams rather take on the technical debt in 1 project so they can move onto other projects.