getting started with testing

[hargi]

Looking for some advice from people who have done this.

I'm not a big tester, and to be honest I haven't done anything in my personal projects. However I am now working for on a large legacy codebase and would like to introduce testing into it.

From the tutorials I have seen they all show you new projects or projects that have tests already in place. Mainly with a add function which is all well and good.
What I want to know is how would you start to introduce tests into a old large project with stuff all over the place.

What would you start with?

 

[mid_gen]

Google for 'automated test framework <insert technology here>'

Setup framework.

Write tests.

Profit.

 

[Gibbs]

You need to automate as much as you can. If its all manual, you'll soon get tired of running the same tests over.

Automated framework depends on type of app. Web apps work well with selenium. Have used Ranrorex for desktop apps, and there support teams are fairly good as well.

 

[The__Malteser]

Automated tests are the way to go as others mentioned. Running your regressions tests periodically will also know whether you broke any old functionality during development (your new code may break an old feature). What I suggest is write a number of tests on the old system (at minimum have tests for the happy paths, although writing some tests for the non-happy paths will help you greatly), write your new code, then write new tests + make sure you didn't break any of the old features.

There are many types of testing; unit testing, end-to-end testing, stress testing etc. Where I used to work, developers used to be responsible for unit tests, integration tests, end-to-end tests and UI tests (my job was predominantly back end but sometimes we needed new screens for new features which is where the UI tests come in). Other teams were responsible for stress testing and whether the application works on staging/production.

In terms of frameworks, these depend on what language your system is written. I was on Java so I mostly used Mockito, Selenium, JUnit and Cucumber. I know that some other people used to use Jasmine (for JS) and Groovy, but I never used them myself (didn't work there for long). Again, you need to look at what frameworks your language provides.

Now, seeing that you are going to start testing an an already existing (and possibly working) system, I would suggest doing the following:
- Have extensive end-to-end tests for each and every functionality (ideally not only the happy paths)
- Have good unit and integration tests for the core/critical functionality (features with absolutely must not break)
You might want to look into code coverage too so you know how much of your code is actually being tested.

Going forward, you might want to look into some testing techniques such as Test Driven Development or Behavior Driven Development. The wikipedia page for Test Automation is quite good tbh and it has some good links to other good wiki pages.

 

[JonJ678]

Michael Feathers wrote "working effectively with legacy code". Read it immediately.

It''s weird that people jump to frameworks. The important part is the test coverage, not the method for reducing boilerplate. You can get a long way with assert.

 

[planty]

What language is the codebase in?

It's likely that the legacy code won't have been written in a 'testable' way, so retrospectively adding tests is going to be quite tricky as you'll have to do a lot of refactoring. Adding automated UI tests first makes a lot of sense, because then you can verify that any refactoring you do in order to add unit/integration tests does not break the UI.

I'd also recommend taking a risk-based approach - analyse the different areas of the legacy code and decide if tests would be worthwhile. For example, if there are areas that are very stable and you never have to touch then adding tests to them is wasted effort. But it makes more sense to start adding tests in areas you are still actively developing/maintaining.