2

When I search for info on testing, all I seem to find is TDD/BDD workflow:

  1. Write a test for a basic functionality
  2. Run and watch if fail
  3. Implement
  4. Run tests again
  5. Fix code if needed
  6. Rinse/repeat until all tests are green

What's the workflow for pre-existing code? Do I write the test with the intention that it will pass with the code that already exists? Do I do steps 1 and 2 without thinking about the code, and then on 3 I fix the code so it will pass the test? I will be using RSpec, and I have implemented behavior and unit tests before.

This project has existed for around 2 years and it has zero tests. I'm a bit overwhelmed.

Improve this question
8
  • Do you have software specifications or requirements of some sort? You want to write to those and verify the code is adhering to it. It will likely be a pass to start, but then going forward you maintain that traceability.
    – mutt
    Commented Mar 15, 2017 at 13:43
  • I don't have anything formal written about requirements, but I've been developing for it for a couple of months, so I think I can write something of the sort myself. I guess that would be a starting point? WRT the actual tests, you're saying that writing them to pass with the existing code is a good strategy?
    – Tuma
    Commented Mar 15, 2017 at 14:02
  • yes, but based on requirements. You want to make sure your existing code is good first and not start off with a bad baseline just cause you had an undiscovered bug. The approved baseline system can be self documenting, but you need to adhere to that baseline for tests and keep mods for changes. In general it's best to have specs that define and go with those even if you have to document as is and go from there. Your tests should hold your system in check and if you don't have anything other than the system to measure against you have nothing to really "check".
    – mutt
    Commented Mar 15, 2017 at 14:31
  • Workflow is like when developing any code: you write the code and watch it fail. :-) Only now, if it fails it is likely a bug in your test code (assuming that app is working correctly, because it was QA tested manually). Rinse and repeat.
    – Peter M. - stands for Monica
    Commented Mar 15, 2017 at 14:34
  • In Agile environments formal requirements are often not done in favor of working software that gets constant feedback and tests that support the code. Untested code is simply technical debt that needs strategies to address it. I've tried to provide some below.
    – Michael Durrant
    Commented Mar 15, 2017 at 14:49

1 Answer 1

Reset to default
1

Technical Debt

You have a described a situation where there is a lot of technical debt from having no tests.

My approach would be:

Change things for all code (new or updated) going forward to have tests.

This doesn't just mean 'require tests', it will mean investing in lots of education, training and introduction of a changed development philosophy and supporting processes.
Currently folks are writing functionality without tests and that is a huge thing to change that will require a lot of effort from all involved.
You may need a coach or contractor who can help you.

It is hard to fully describe the feelings I've had going from before with no tests (terrified of breaking stuff, clueless if I'm breaking stuff) to after with good tests (safe, secure, protected, covered, calm).

Use a code coverage tool to list what needs testing in the codebase

codecov and code climate are 2 examples here

Enter tickets for the technical debt tests

You will need to balance them against new feature/bug development

Use local linting tools

For ruby, rubocop

Use a CI environment to run the test suites

consider having some technical debt weeks to address the untested code

Figure out which Unit, Integrated and User Acceptance tests should be written

One route might be to start with User Acceptance tests using RSpec and capybara against a real browser. This gives you immediate end-to-end testing of all the components. Then I would probably focus on model tests which is where your business logic should be grouped, finally doing controller tests as integration testing.

More on the Testing Pyramid and the Quandrants of Agile testing at https://sqa.stackexchange.com/a/23396/8992

Improve this answer
3
  • Thanks so much, Michael! As a follow-up question: is there any formal way of estimating the time to catch up on this debt? I know that when it comes to programming, time estimates are often imprecise, but my boss asked how long implementing tests would take, and I don't know what number to give him.
    – Tuma
    Commented Mar 15, 2017 at 14:53
  • Avoid giving a time estimate at all costs until pushed to the wall. Delay, delay, delay that answer. Talk about how long to get say, happy path User Acceptance testing for the most common workflow in one browser. Get that done and then repeat. I'm working on an application with a small company where view tests (capybara) took 6 months to get good coverage. We're doing missing controller tests now and the app is about 4 years old... We're still developing the app quite heavily at the same time. We have a team of 10-15 to do this.
    – Michael Durrant
    Commented Mar 15, 2017 at 14:59
  • Put a simpler way, in Agile the application development is never done and neither is testing. There will always be a testing backlog of some sort or form.
    – Michael Durrant
    Commented Mar 15, 2017 at 15:30

Your Answer

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

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