5

There are only two members in our development team and we started to work on a medium scale web application (Laravel).

My question is about testing especially TDD, Do we really start to follow TDD strictly or start development without any test framework and later hire some developers for testing?

But if we didn't follow a test pattern how the testers (They will come after sometime) deal with the existing code base.

Improve this question
4
  • You absolutely need to test from the beginning. If you build a subsystem without any kind of testing it will almost certainly not work correctly, and it could contain fundamental design errors.
    – JacquesB
    Mar 10, 2017 at 8:39
  • Of course tests never catch all errors; only proofs can do that.
    – Frank Hileman
    Mar 10, 2017 at 8:54
  • 1
    Are you sure you're not mixing the method TDD and just have non-regression test ? You don't spécifically need TDD to have non-regression tests.
    – Walfrat
    Mar 10, 2017 at 13:01
  • 2
    "You only need to test the code you want to work." ~Wise man
    – RubberDuck
    Mar 10, 2017 at 14:27

3 Answers 3

Reset to default
9

If you are starting a greenfield project I would urge to start automated testing from the start. Doing everything TDD might be a challenge if the team has low experience with TDD. Still setting a minimum code coverage target of let's say 65% makes sure the code is testable.

Why would you want to automate your tests:

  • Being able to refactor the code safely as the requirements change or to keep the code clean and readable
  • Release often with confidence, preferable without recurring manual testing
  • Being able to add tests when defects do happen, prevent them from recurring

I would write at least:

  • A couple of unit-tests for each class
  • A integration test that bootstraps the system
  • Write a single end-2-end test for each feature (To make sure the UI is testable. Use PageObjects to make it maintainable)

Adding tests to a system not designed to be automated tested is probably never going to happen, since it pretty hard and time consuming. It will be a frustrating situation and testers will prefer manual testing slowing you down. If you need a fast to market cycle or being able to pivot the product focus on test automation from the start. If you don't your product will probably resist change.

Teaching developers TDD:

Improve this answer
3

Strict Test Driven Development requires the test for the next bit of code to be written before the tested code is written. In this way, the attempt to use the API positively influences the development of the API. Writing documentation before implementation can have a similar influence.

You cannot call it TDD if the tests are written afterwards.

The tests themselves are not always useful for testing in the long term, as they tend to be redundant, break encapsulation, and can be difficult to maintain. It's more of a design technique, with automated testing as a side effect.

Improve this answer
1

Niels van Reijmersdal gave a great answer https://softwareengineering.stackexchange.com/a/343862/55065 let me add two cents to that.

TDD or not, better to have tests even if you write it after writing code. Just write then right away.

Apart from testing part the test also communicates the programmer intent: "How the code program should behave when I do ...".

You don't need 100% coverage, and don't have to follow strict TDD, but if you try two things will happen: 1. You'll become better and better at TDD 2. Your code will be easier to test in most parts (this is an automatic benefit of TDD). Easier doesn't mean easy, especially when you're unexperienced (see point 1).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.