I preach a lot about using test driven development to boss but I have been unable to use TDD myself in the project because the other developer hates writing specs since he thinks it is very time consuming.
So I just got scolded real bad for saying about TDD and using a mentor but unable to show and prove to him the benefits of TDD. I am myself confused why to use it. I only know it can help us with automated testing.
I am unable to explain to him how to do test driven development and when the architecting the solution comes into the process of TDD.
for example we are using atleast 50 if statements right now to do something but I have no idea how to convert the ifs into a rule engine and move out the logic. I just started to read about rules engine.
He scolded me about saying about TDD but still ysing 50 if statements. I was unable to explain anything to him about how TDD works and when the designing the system comes into the process
@ben@cpytel@arunagw
Please help me here. Got scolded real real bad. What should I do now?
I think the first avenue of attack, even though it isnât the primary benefit of TDD, is to preach the benefits of protection against regresssion. If you are writing tests before you fix any broken code (when a bug report comes in), you are by definition protecting yourself against a recurrence of the same bug again.
Some managers just wonât listen, and in those cases I would just write the tests anyway as part of your work. Even if youâre the only one writing tests for now, itâs not slowing you down (if it is, it wonât for long, as you get better at it), and itâs putting positive design pressure on your code (the main benefit of TDD).
If you get scolded for writing tests (even if youâre not forcing that work on other people), you need to go find a new job. Developers are in demand. Vote with your feet.
thanks @geoffharcourt. I could atleast not tell him anymore about TDD but still use TDD internally within my work. That makes more sense. And I should not try to force the other developer to use TDD if he doesnt want to. But how can I use TDd without writing any integration tests? Because I were to write one scenario using specs but what if the other developer changed the implementation code with changing my specs? What will I do in that case ?
TDD or BDD will help you to have a better architecture. If itâs complicated to test, there is probably an architectural problem.
I suggest you to user BDD insteed TDD. You should create a high level test and write a unit test for each part of this high level test. If another developer broke your test you can just say âhey, you change the behaviour of a working part of the application. Why?â. A high level test must be what the client want to see in his application so if it break, it is probably because the new code does not respect what the client want.
With the experience, you will made more stable applications.
To start, Iâd focus on unit testing your own code, because then you at least have control over what youâre working on. Once you are more confident in your own practice of TDD on your own code, you can start making use of integration tests, and maybe gently using them to show your team where things are failing (âHey, I just found a bug that we wouldnât have expected in last nightâs build!â)
Writing non-brittle (flexible?) integration tests is hard. They are a really important part of a test suite, but in your current situation where you have an uphill cultural climb with regard to testing, I would focus more on unit tests and maybe some integration tests on parts of the application that you alone are mostly responsible for (if such areas exist) to avoid breakage over teammates who arenât interested.
My advice is not to say that integration tests arenât a good idea, just that you need to establish a âbeachheadâ of solid tests before you can make a stronger case with skeptical coworkers.
I worked at more than one company where developers talked openly about the futility of testing, and watched mediocre software get shipped. In one case the company let a couple developers who did a terrible job while demo-ing TDD (they were goofing off and not working) permanently color their feelings about testing. As a result, they are incapable of growing.
