Home/ Questions/Q 216879
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T18:36:20+00:00

I just looked back through the project that nearly finished recently and found a

  • 0

I just looked back through the project that nearly finished recently and found a very serious problem. I spent most of bank time on testing the code, reproducing the different situations “may” cause code errors.

Do you have any idea or experience to share on how to reduce the time spent on testing, so that makes the development much more smoothly?

I tried follow the concept of test-driven for all my code , but I found it really hard to achieve this, really need some help from the senior guys here.

Thanks

Re: all

Thanks for the answers above here, initially my question was how to reduce the time on general testing, but now, the problem is down to how to write the effecient automate test code.

I will try to improve my skills on how to write the test suit to cut down this part of time.

However, I still really struggle with how to reduce the time I spent on reproduce the errors , for instance, A standard blog project will be easy to reproduce the situations may cause the errors but a complicate bespoke internal system may “never” can be tested throught out easily, is it worthy ? Do you have any idea on how to build a test plan on this kind of project ?

Thanks for the further answers still.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Test driven design is not about testing (quality assurance). It has been poorly named from the outset.

    It’s about having machine runnable assumptions and specifications of program behavior and is done by programmers during programming to ensure that assumptions are explicit.

    Since those tasks have to be done at some point in the product lifecycle, it’s simply a shift of the work. Whether it’s more or less efficient is a debate for another time.

    What you refer to I would not call testing. Having strong TDD does mean that the testing phase does not have to be relied upon as heavily for errors which would be caught long before they reach a test build (as they are with experience programmers with a good spec and responsive stakeholders in a non-TDD environment).

    If you think the upfront tests (runnable spec) is a serious problem, I guess it comes down to how much work the relative stages of development are expected to cost in time and money?

    • 0