Working on legacy systems with absolutely no tests

[Mohamed Sanaulla]

There would be legacy systems with absolutely no tests and absolutely no integration with a testing framework. Adding Unit tests would be quite difficult as the code is not structured in a way that we can unit test them. I have been thinking of UI or End to End tests but then time taken to incorporate such an activity would be a critical concern.

With atleast End to end tests I can automate the testing when ever I make any changes. Otherwise I would have to manually test all the scenarios.

What would be your advice in approaching adding tests and integration with tests framework?

[atul khot]

Hi Mohamed,
A very good point you made - far too much code gets written this way... no tests, there is a scramble to get something working out fast...
And win the confidence of the stakeholders...
Adding tests later is a non-trivial undertaking - I did attempt it at times - and have frustrating memories - the time to rework things is prohibitive...

[Joe San]

This is what happens if you have your stake holders that does not understand the risk of an untested code.

[Junilu Lacar]

Joe Harry wrote:This is what happens if you have your stake holders that does not understand the risk of an untested code.

I think it's a cop-out to try to blame stake holders for the sloppy job that developers do. It's the developer's responsibility to write unit tests and ensure quality of their code. Don't blame the houseowner for not making sure that you, the housebuilder, followed good construction/engineering practices.

For new code, I never ask permission to do TDD or refactor. It's just all a part of good software development practice; it's what I do as a developer. For legacy code, I might have some discussions with the stakeholders to educate them on the risks and costs of moving forward without refactoring the code first. They can then weigh those risks and costs and decide whether or not they want to invest in giving the developers time to refactor/reengineer the code so that they can proceed safely and more quickly from there. I usually end up giving them a little "lecture" about Technical Debt but most of the time, we can all come to a consensus on whether or not refactoring the legacy code is a good investment. Sometimes I get my way, which is always to refactor, sometimes not but at least I always have the stakeholders on board and expectations are set clearly and appropriately.

[Yvette Schat]

Junilu Lacar wrote:

Joe Harry wrote:This is what happens if you have your stake holders that does not understand the risk of an untested code.

I think it's a cop-out to try to blame stake holders for the sloppy job that developers do. It's the developer's responsibility to write unit tests and ensure quality of their code. Don't blame the houseowner for not making sure that you, the housebuilder, followed good construction/engineering practices.

True. It's part of the craftmanship/professionalism of the developer to ensure code quality.

The stakeholders can be blamed for other things, e.g. sloppy/inexistent acceptance tests of the end-product.

[Junilu Lacar]

Yvette Schat wrote:The stakeholders can be blamed for other things, e.g. sloppy/inexistent acceptance tests of the end-product.

Even that is a cop-out to me. Developers have a responsibility to work with their stakeholders and guide them through the process of acceptance. Throwing software over the fence and saying, "Here, see if you can find any problems with that. If you don't tell us now, then it's all on you if you get burned later" is no different from what Microsoft does in releasing buggy versions of Windows to the general public. Sure, there are strategic reasons for releasing software that has known problems but to put the blame on the users is shirking responsibility.

Good software development is about constant collaboration between everyone involved in the process. Quality is everyone's responsibility but IMO it all starts with the developers. Developers should step up and do their jobs.

[Yvette Schat]

Junilu Lacar wrote:

Yvette Schat wrote:The stakeholders can be blamed for other things, e.g. sloppy/inexistent acceptance tests of the end-product.

Even that is a cop-out to me. Developers have a responsibility to work with their stakeholders and guide them through the process of acceptance.

I don't agree. True that there must be collaboration, but the business is grown up and should not expect a babysitter and whine when things do not work ;-)
It's symbiotic.

[Junilu Lacar]

Yvette Schat wrote:I don't agree. True that there must be collaboration, but the business is grown up and should not expect a babysitter and whine when things do not work ;-)
It's symbiotic.

I don't see that as a useful attitude. If you think that the act of working with stakeholders and guiding them through the process of acceptance is "babysitting" and that bringing up issues with the software is "whining" then I think we have different working definitions of "collaboration".

When I bought my house, the building foreman often did "walkthroughs" with us to point out different aspects of the house and its construction. Some of the things that were pointed out would not have been things we'd notice if the foreman didn't bring them to our attention. Similarly, developers have a responsibility to walk the stakeholders through the implementation and point out things they wouldn't notice otherwise.

[Mohamed Sanaulla]

Agree with Junilu, its our developers responsibility to incorporate tests.

There have been different experiences for me working on 3 different places - First had good test integration and I could easily add new tests to cover any refactoring/new implementations in the legacy code. Second one had tests but never got executed but I managed to unit test what ever code I added but there were no E2E tests. Third one there is absolutely no test integration and its a relatively new area for me. I would be working on atleast adding E2E tests.

How has been your approach to adding tests for the code base which absolutely has no integration with test framework and which is using ant as build tool?

[Yvette Schat]

Junilu Lacar wrote:

Yvette Schat wrote:I don't agree. True that there must be collaboration, but the business is grown up and should not expect a babysitter and whine when things do not work ;-)
It's symbiotic.

I don't see that as a useful attitude. If you think that the act of working with stakeholders and guiding them through the process of acceptance is "babysitting" and that bringing up issues with the software is "whining" then I think we have different working definitions of "collaboration".

I agree to disagree. Stakeholders have an active role in quality, the role of the developer ends at a certain point in time.
Only then you can have closure, needless to say a good developer distinguishes his/herself by guaranteeing the product
is of the best quality possible.

[Junilu Lacar]

Yvette Schat wrote:Stakeholders have an active role in quality, the role of the developer ends at a certain point in time.

No argument from me about these.

IMO, the developer's responsibility ends when the stakeholder accepts the work. Until then, the developers and stakeholders have to collaborate to make sure the other party is getting the right input and feedback about quality. Like you said, it's a symbiotic relationship but just as my relationship with my house builder ended when I signed the papers and moved into my house, the relationship between developer and stakeholder, at least for the features that are being delivered, ends when the stakeholder accepts the work product. That's when closure happens. In fact, the house building/buying analogy works very well for this; the term used in the real estate industry in the US is "closing on the house."

[Karthick Sundaram]

Hi all,

This is a problem that we have in my current project. We have very few tests and the application that we have built is a monster and the number of developers is so huge. And the management think that if 10 developers do a job in 10 days, then 100 developers can do the same job in 1 day. We touch one piece of code and it breaks several existing functionalities. So what gets added is a hack finally. And every body is risk averse to refactor. We have a few Junits and a few Selenium tests.

So let us say there is some piece of software that we are required to maintain and that is a distributed application and no tests existing. We have lots of new requirements coming up, which we will have to build into the existing system, without breaking existing functionality. How do we start. I believe it starts with writing tests for existing functionality and then refactoring them as needed. and then proceeding for developing new features. Please let me know if otherwise.
Here we are talking about a distributed application. How do we start.
If we thought of a SOA project, where everything is decoupled from everything else and there is indirection. We do not have the definite list of consumers and producers for the services that we have. How do we start writing our tests.

Eagerly looking forward to your answers.

Thanks,
Karthick

[Junilu Lacar]

It's hard to be specific about these things. In general though, I always fall back to basic design principles and design patterns. Most problems come from violating the SOLID, SLAP, and DRY design principles. If you use modern frameworks properly, a lot of the technical issues are already taken care of for you by the framework developers. Knowing how to use the frameworks properly and making good design choices based on the basic principles keeps you out of a lot of trouble.

Another book that I find very useful is Joshua Kerievsky's "Refactoring to Patterns". The strategies suggested by this book and those in the WELC book are very powerful tools that can help you get software to a better place. Hopefully, Chris' book will be a good complement to these.

[Joe San]

Junilu Lacar wrote:

Joe Harry wrote:This is what happens if you have your stake holders that does not understand the risk of an untested code.

I think it's a cop-out to try to blame stake holders for the sloppy job that developers do. It's the developer's responsibility to write unit tests and ensure quality of their code. Don't blame the houseowner for not making sure that you, the housebuilder, followed good construction/engineering practices.

For new code, I never ask permission to do TDD or refactor. It's just all a part of good software development practice; it's what I do as a developer. For legacy code, I might have some discussions with the stakeholders to educate them on the risks and costs of moving forward without refactoring the code first. They can then weigh those risks and costs and decide whether or not they want to invest in giving the developers time to refactor/reengineer the code so that they can proceed safely and more quickly from there. I usually end up giving them a little "lecture" about Technical Debt but most of the time, we can all come to a consensus on whether or not refactoring the legacy code is a good investment. Sometimes I get my way, which is always to refactor, sometimes not but at least I always have the stakeholders on board and expectations are set clearly and appropriately.

When the time given to develop something is calculated or estimated without taking testing effort into consideration, how would you write tests? This happened to me a couple of times where there was a person part of the Stakeholder team estimated the development effort which had to be blindly followed. What would you do in that case? Unanimously, that stake holder was held responsible for putting us in a situation to deliver un unit tested code base.

I have experienced over the years that I gained a lot of reputation by delivering quality software and I was able to do this by writing as much unit tests as I could to make my code base more robust.

[Junilu Lacar]

Joe Harry wrote:
When the time given to develop something is calculated or estimated without taking testing effort into consideration, how would you write tests? This happened to me a couple of times where there was a person part of the Stakeholder team estimated the development effort which had to be blindly followed. What would you do in that case? Unanimously, that stake holder was held responsible for putting us in a situation to deliver un unit tested code base

I would not let the stakeholder estimate work that they were not doing themselves. If they insisted on doing the estimates, then I would insist that they do the work.

However, you may not have enough influence to do that. Then I would remind them that they are not doing the work and it's not fair for them to give the estimate. Remind them that there are other things that need to be done that they may not be taking into account. Remind them that estimates are not exact and that if you make them "hard" then they are no longer estimates. Remind them, remind them, remind them.

What you describe there, Joe, is a dysfunctional organization. You let yourself fall victim to it by not having the right conversations with the stakeholders. At the very least, if you can't negotiate with stakeholders like what you describe, you should CYA and document the fact, via emails or signed documents, that you advised something, detailed the consequences of not following the advice, tried your best to do the right thing, but had your advice ignored or rejected. Then I would start looking for another job because it's not worth that kind of aggravation.

*CYA = Cover Your A$$

[Junilu Lacar]

I think it was Martin Fowler who said, "If you can't change your organization, change your organization."

[Junilu Lacar]

I took another look at the free chapter for Chris' book and section 1.4 talks about Legacy Culture. It doesn't look like there is any more discussion about culture in the rest of the book though. Maybe Chris can clarify.

Lately, I have noticed more people have been citing Conway's Law which is good because I have found it to be absolutely true and it's critical that managers understand the consequences that their org structures have on the quality of the software that they produce.

[T. Sharma]

I would like to go to the original question. Unfortunately, it is not rare to see such cases (where tests are completely missing). To counter this, Michael Feathers proposed the "legacy code change algorithm" in his book (Working Effectively with Legacy code):

Identify change points

Find test points

Break dependencies

Write tests

Make changes and refactor

One should try to follow this to overcome the situation. It is to be realized that the situation cannot be changed completely overnight.

A quote from the same source (that I like a lot): "Over time, tested areas of the code base surface like islands rising out of the ocean."

[Junilu Lacar]

T. Sharma wrote:I would like to go to the original question.
...
A quote from the same source (that I like a lot): "Over time, tested areas of the code base surface like islands rising out of the ocean."

Thanks for unhijacking the topic

One thing that often gets left out of these efforts are the conversations that should happen. At the risk of rehijacking the topic, you should make sure that everyone involved, including the stakeholders, are on the same page as to how much effort is worth putting into refactoring. You may be able to get away with refactoring on the sly for a little while but eventually the slowdown will get noticed if the cumulative effort is large enough.

Using the islands of tested code works well both as an execution strategy and as a selling pitch to stakeholders.

[Karthick Sundaram]

T. Sharma wrote:I would like to go to the original question. Unfortunately, it is not rare to see such cases (where tests are completely missing). To counter this, Michael Feathers proposed the "legacy code change algorithm" in his book (Working Effectively with Legacy code):

Identify change points

Find test points

Break dependencies

Write tests

Make changes and refactor

One should try to follow this to overcome the situation. It is to be realized that the situation cannot be changed completely overnight.

A quote from the same source (that I like a lot): "Over time, tested areas of the code base surface like islands rising out of the ocean."

Exactly What I was looking for. Thank you very much. :-)

[Karthick Sundaram]

Junilu Lacar wrote:It's hard to be specific about these things. In general though, I always fall back to basic design principles and design patterns. Most problems come from violating the SOLID, SLAP, and DRY design principles. If you use modern frameworks properly, a lot of the technical issues are already taken care of for you by the framework developers. Knowing how to use the frameworks properly and making good design choices based on the basic principles keeps you out of a lot of trouble.

Thank you for the SOLID, SLAP, and DRY design principles. I am writing and have written code that adheres to some of these priniciples. I will try to incorporate the remaining into my mind, so that it gets used when I write code from now on. But the problem I have had is - When you give an estimate of time required to complete a task, that includes writing tests, I am asked, what would be the estimate without the tests. :-) That to me is like some one looking to buy a car and bargaining with you, that I do not need the brakes, what is the price now. I am not able to justify the use of tests and I think that they need to be educated about the craft of software development.

[Tim Cooke]

Karthick Sundaram wrote:But the problem I have had is - When you give an estimate of time required to complete a task, that includes writing tests, I am asked, what would be the estimate without the tests. :-)

I would resist giving that estimate at all. As you say, it's like asking the car dealer to forget about the brakes to cut a week off the delivery date.

'Uncle' Bob Martin uses the Surgeon washing his hands analogy when you ask him about this. He proposes that it's a matter of professionalism that we insist on writing tests for any code we write, in the same way that it's a matter of professionalism that the Surgeon washes his hands before performing an operation. You should not be coerced into writing untested code like the Surgeon should not be coerced into operating with dirty hands.

You may think this example a bit extreme, and it is a little, but the message is important. It is the job of the programmer to educate those around her that writing tests is an integral and essential part of writing good quality software that cannot be omitted.

On a lighter note, a glib answer might be "You can have it for whenever you want, as long as it doesn't have to work"

[Junilu Lacar]

Tim Cooke wrote:On a lighter note, a glib answer might be "You can have it for whenever you want, as long as it doesn't have to work"

Thanks for reminding me about Uncle Bob's surgeon analogy.

Still funny, although a bit more edgy: "Estimate? NFC." https://twitter.com/pawelbrodzinski/status/493730902241861633

[Chris Birchall]

Looks like I'm a bit late to the party here, But I was interested by this part of the original post:

Mohamed Sanaulla wrote:I have been thinking of UI or End to End tests but then time taken to incorporate such an activity would be a critical concern.

Actually, writing UI tests is not as difficult and time-consuming as maybe you imagine. I often use Capybara to write UI tests, because I like the readability of its Ruby DSL. There's very little setup needed, and each test is only a few lines of code. If you're not a fan of Ruby, there's always Selenium or FluentLenium.

If you're working with legacy code and it's difficult to break dependencies and add unit tests, UI tests might be the best place to start. Once you have those in place, you can work your way in, writing component-level functional tests and eventually unit tests.

One common problem encountered when writing UI tests is that the HTML was not written with testing in mind, so it's difficult to find a particular element using XPath or CSS selectors. But this is easily fixed by sprinkling a few id attributes through the HTML.