Refactoring the code or dessign?
-
It's not so strange. There are many cases where constructing unit tests would in itself represent a huge development effort, and I for one disagree that it is a necessarily a good idea to do so when about to embark on a refactoring. The project I work on is a point in case. It is a web application and it isn't easy to unit test, among other reasons because intrinsic asp.net objects (request, response, session state, application state, httpserverutility) are used indiscriminately anywhere, so to make a unit test for some business class you need to make mocks of these, which you can't, because they are all sealed classes. Even if you could it would be quite a bit of extra work. And if your refactoring involves removing all these objects from your business logic you don't get any long-term benefit from doing all that work - once your tests are developed your refactoring then breaks them! And that leads me to the more general observation: Refactoring isn't (usually) just about changing implementation details; it usually involves interface changes, decoupling of objects, and construction logic changes - perhaps introducing a factory somewhere. Most of these changes are of a nature that make them very likely to break any tests. So why do all the development effort to make a bunch of tests that you will immediately go about invalidating? In my view, far better to refactor and make tests for your *new* code as you go. In the end, if you had bugs that are still there after the refactoring there is no reason to think the refactoring itself would make them harder to fix afterwards, and if your refactoring introduced bugs that is no different to if you had made the unit tests for the "before refactoring" version of the application. So I don't get it. What would be the great benefit of developing tests to know that some code you're about to change works, when those tests cannot be reused to test the code after the changes?
dojohansen wrote:
There are many cases where constructing unit tests would in itself represent a huge development effort
Therefore your conclusion is to not do it? :omg::wtf: That's going to make reading the rest of your post difficult, but I will try.
dojohansen wrote:
because intrinsic asp.net objects (request, response, session state, application state, httpserverutility) are used indiscriminately anywhere
Bad, bad design, period.
dojohansen wrote:
so to make a unit test for some business class you need to make mocks of these
No you don't, well you do apparently but I don't because I don't tightly couple business objects to ASP.NET intrinsics that are Presentation Layer objects. See Separation of Concerns[^], Isolation and Object Oriented Design Principles and Best Practices.
dojohansen wrote:
So I don't get it.
Clearly.
dojohansen wrote:
What would be the great benefit of developing tests to know that some code you're about to change works, when those tests cannot be reused to test the code after the changes?
Once again it's about how you Design your Unit Tests, it's about the cases, the cases should be able to be reused on the new Unit Test code you write for the new refactoring of things. This way you have the same test coverage of the new code as you did on the old code. Final note: Avoiding work is NOT a valid excuse for not testing. If it were, software in general would be a lot worse quality than it already is. ;)
led mike
-
dojohansen wrote:
There are many cases where constructing unit tests would in itself represent a huge development effort
Therefore your conclusion is to not do it? :omg::wtf: That's going to make reading the rest of your post difficult, but I will try.
dojohansen wrote:
because intrinsic asp.net objects (request, response, session state, application state, httpserverutility) are used indiscriminately anywhere
Bad, bad design, period.
dojohansen wrote:
so to make a unit test for some business class you need to make mocks of these
No you don't, well you do apparently but I don't because I don't tightly couple business objects to ASP.NET intrinsics that are Presentation Layer objects. See Separation of Concerns[^], Isolation and Object Oriented Design Principles and Best Practices.
dojohansen wrote:
So I don't get it.
Clearly.
dojohansen wrote:
What would be the great benefit of developing tests to know that some code you're about to change works, when those tests cannot be reused to test the code after the changes?
Once again it's about how you Design your Unit Tests, it's about the cases, the cases should be able to be reused on the new Unit Test code you write for the new refactoring of things. This way you have the same test coverage of the new code as you did on the old code. Final note: Avoiding work is NOT a valid excuse for not testing. If it were, software in general would be a lot worse quality than it already is. ;)
led mike
I wrote a sincere and I would say well considered opinion about a subject relevant to some people, and certainly to the original question posted. Your reply can be summed up as you trying to tell me "you're an idiot". I am sure the person who asked the question is able to judge the reasons given for and against any recommendation and I suggest you stick to explaining why he should develop unit tests before refactoring and let readers draw their own conclusions. Your venomous, arrogant reply was quite provocative. If it were not for the fact that your arrogance is - incredibly - superseded by your stupidity, I'd take it as a bitter pill and just try to learn from it. As it is, I'll take issue with your "argument". We are not discussing the quality of the application code in the project I work on. It should be blindingly obvious to all of us why using, say, session state in a business object is just plain wrong. I was debating whether or not *generally* speaking it is smart to develop unit tests BEFORE or AFTER a refactoring of code. Unfortunately not one word you input related to this subject, so I can only say I am unused to "debating" at this level and not quite certain how I can best help you see the light. I will try though, adding some emphasis especially for you: It is my OPINION that it is not ALWAYS or AUTOMATICALLY best to develop unit tests PRIOR TO REFACTORING CODE. If developing the tests represents a SIGNIFICANT WORKLOAD that would be UNDONE by the subsequent refactoring, it is my opinion that it is A WASTE OF TIME to do it IN THIS ORDER. Furthermore, I claim that in the real world, MOST (this is not quite the same as all) refactoring would be of such a nature as to be very likely to break any unit tests developed. Hence, if about to refactor a project for which no unit tests exist, it MAY be a GOOD IDEA to CONSIDER whether one should refactor FIRST and THEN develop the unit tests. If you don't have anything more intelligent to say than "avoiding work is NOT a valid excuse" when I haven't even remotely suggested anything of the kind then PLEASE, just spare us. You are neither funny or enlightning. Working hard is not sufficient in software development, you have to use your brain too. So do it.
-
I wrote a sincere and I would say well considered opinion about a subject relevant to some people, and certainly to the original question posted. Your reply can be summed up as you trying to tell me "you're an idiot". I am sure the person who asked the question is able to judge the reasons given for and against any recommendation and I suggest you stick to explaining why he should develop unit tests before refactoring and let readers draw their own conclusions. Your venomous, arrogant reply was quite provocative. If it were not for the fact that your arrogance is - incredibly - superseded by your stupidity, I'd take it as a bitter pill and just try to learn from it. As it is, I'll take issue with your "argument". We are not discussing the quality of the application code in the project I work on. It should be blindingly obvious to all of us why using, say, session state in a business object is just plain wrong. I was debating whether or not *generally* speaking it is smart to develop unit tests BEFORE or AFTER a refactoring of code. Unfortunately not one word you input related to this subject, so I can only say I am unused to "debating" at this level and not quite certain how I can best help you see the light. I will try though, adding some emphasis especially for you: It is my OPINION that it is not ALWAYS or AUTOMATICALLY best to develop unit tests PRIOR TO REFACTORING CODE. If developing the tests represents a SIGNIFICANT WORKLOAD that would be UNDONE by the subsequent refactoring, it is my opinion that it is A WASTE OF TIME to do it IN THIS ORDER. Furthermore, I claim that in the real world, MOST (this is not quite the same as all) refactoring would be of such a nature as to be very likely to break any unit tests developed. Hence, if about to refactor a project for which no unit tests exist, it MAY be a GOOD IDEA to CONSIDER whether one should refactor FIRST and THEN develop the unit tests. If you don't have anything more intelligent to say than "avoiding work is NOT a valid excuse" when I haven't even remotely suggested anything of the kind then PLEASE, just spare us. You are neither funny or enlightning. Working hard is not sufficient in software development, you have to use your brain too. So do it.
dojohansen wrote:
I was debating whether or not *generally* speaking it is smart to develop unit tests BEFORE or AFTER a refactoring of code. Unfortunately not one word you input related to this subject
Perhaps it's because you replied to my post that said:
led mike wrote:
Yes. It's hard to imagine someone is thinking about design and architecture and refactoring but they haven't yet thought about the fact they should have unit tests. As hard as it might be to imagine that someone, no doubt they exist.
What I was discussing in that post as well as my last one to you was the importance of Unit Tests during INITIAL DEVELOPMENT. The original post used terms like "old architecture" which I took to mean in production.
dojohansen wrote:
It is my OPINION that it is not ALWAYS or AUTOMATICALLY best to develop unit tests PRIOR TO REFACTORING CODE
It's my opinion that it's insane to be in production without unit tests. And no this is not some new belief based on TDD, I learned to use Unit Tests long before I ever heard the term Test Driven Development and long before any frameworks existed, AFAIK. Therefore I was never discussing the merits of developing unit tests based on a need to refactor in post production since the Unit Tests would already exist prior to production. My comments were only to the point of developing unit tests as a standard practice of software development, period. So you can get as upset as you want with what I said, it doesn't change any of that.
led mike
-
dojohansen wrote:
I was debating whether or not *generally* speaking it is smart to develop unit tests BEFORE or AFTER a refactoring of code. Unfortunately not one word you input related to this subject
Perhaps it's because you replied to my post that said:
led mike wrote:
Yes. It's hard to imagine someone is thinking about design and architecture and refactoring but they haven't yet thought about the fact they should have unit tests. As hard as it might be to imagine that someone, no doubt they exist.
What I was discussing in that post as well as my last one to you was the importance of Unit Tests during INITIAL DEVELOPMENT. The original post used terms like "old architecture" which I took to mean in production.
dojohansen wrote:
It is my OPINION that it is not ALWAYS or AUTOMATICALLY best to develop unit tests PRIOR TO REFACTORING CODE
It's my opinion that it's insane to be in production without unit tests. And no this is not some new belief based on TDD, I learned to use Unit Tests long before I ever heard the term Test Driven Development and long before any frameworks existed, AFAIK. Therefore I was never discussing the merits of developing unit tests based on a need to refactor in post production since the Unit Tests would already exist prior to production. My comments were only to the point of developing unit tests as a standard practice of software development, period. So you can get as upset as you want with what I said, it doesn't change any of that.
led mike
Somebody's been really hammering you with 1 votes on this board Mike. I've corrected the balance on some of them, and will continue to do so as time allows.
Deja View - the feeling that you've seen this post before.
-
Somebody's been really hammering you with 1 votes on this board Mike. I've corrected the balance on some of them, and will continue to do so as time allows.
Deja View - the feeling that you've seen this post before.
Pete O'Hanlon wrote:
Somebody'
:laugh: Yeah, probably the same guy that was giving you the 2's. He explained that was an accident though. Apparently he didn't like my response to his argumentative reply in this thread about the importance of Unit Tests. Like I give a crap what he thinks. :laugh::laugh:
led mike
-
Pete O'Hanlon wrote:
Somebody'
:laugh: Yeah, probably the same guy that was giving you the 2's. He explained that was an accident though. Apparently he didn't like my response to his argumentative reply in this thread about the importance of Unit Tests. Like I give a crap what he thinks. :laugh::laugh:
led mike
Ahhh. Yup - I was reading this thread through with interest, especially because it highlights the differences in opinion in whether or not UT is important. It's a shame that people miss the point that good up front UT is a great way to force yourself to think more about the architecture of the system, and to look at putting good practices into place.
Deja View - the feeling that you've seen this post before.
-
Ahhh. Yup - I was reading this thread through with interest, especially because it highlights the differences in opinion in whether or not UT is important. It's a shame that people miss the point that good up front UT is a great way to force yourself to think more about the architecture of the system, and to look at putting good practices into place.
Deja View - the feeling that you've seen this post before.
Pete O'Hanlon wrote:
It's a shame that people miss the point
Sure, it's one in long list of points people miss in this field regarding good practices. witnessed here every single day. "here" having multiple usages: 1) Code Project 2) My peers and *gulp* managers or where I work 3) Me myself and I :laugh: Well maybe I don't miss them as much as I don't know them. I remember when I started out in University we worked with Unix and DOS. This was pre Windows and PCs were starting to move out so DOS became the hot bed. My internship, which became a job (long story or not), was DOS POS, yes Point of Sale and Piece of Shite. :laugh: Anyway back then my vision of the future was I would be one of these guys that new almost everything about PC development. Then came (for me) OO, Windows and the Internet, etc., and I soon realized I would ever only scratch the surface or not, depends on your point of view. Most days it feels like not. Anyway people that don't have a clue and don't even try, those that ignore people like Cunningham, Fowler, Beck, Booch and well there are just so many, as though they think they know better than they do I find annoying, at best, at worst they seem disgraceful. For my part I just hope I can even understand their points, the idea that I could judge them is not something I would even consider.
led mike
-
Pete O'Hanlon wrote:
It's a shame that people miss the point
Sure, it's one in long list of points people miss in this field regarding good practices. witnessed here every single day. "here" having multiple usages: 1) Code Project 2) My peers and *gulp* managers or where I work 3) Me myself and I :laugh: Well maybe I don't miss them as much as I don't know them. I remember when I started out in University we worked with Unix and DOS. This was pre Windows and PCs were starting to move out so DOS became the hot bed. My internship, which became a job (long story or not), was DOS POS, yes Point of Sale and Piece of Shite. :laugh: Anyway back then my vision of the future was I would be one of these guys that new almost everything about PC development. Then came (for me) OO, Windows and the Internet, etc., and I soon realized I would ever only scratch the surface or not, depends on your point of view. Most days it feels like not. Anyway people that don't have a clue and don't even try, those that ignore people like Cunningham, Fowler, Beck, Booch and well there are just so many, as though they think they know better than they do I find annoying, at best, at worst they seem disgraceful. For my part I just hope I can even understand their points, the idea that I could judge them is not something I would even consider.
led mike
led mike wrote:
I soon realized I would ever only scratch the surface
Yup - the more I learn, the more it becomes apparent that there's more to learn. For me, the forums are a great place to learn from people I respect. Even if I don't often ask questions on the forums, it's amazing how much I've picked up from the better answers.
Deja View - the feeling that you've seen this post before.
-
led mike wrote:
I soon realized I would ever only scratch the surface
Yup - the more I learn, the more it becomes apparent that there's more to learn. For me, the forums are a great place to learn from people I respect. Even if I don't often ask questions on the forums, it's amazing how much I've picked up from the better answers.
Deja View - the feeling that you've seen this post before.
-
dojohansen wrote:
I was debating whether or not *generally* speaking it is smart to develop unit tests BEFORE or AFTER a refactoring of code. Unfortunately not one word you input related to this subject
Perhaps it's because you replied to my post that said:
led mike wrote:
Yes. It's hard to imagine someone is thinking about design and architecture and refactoring but they haven't yet thought about the fact they should have unit tests. As hard as it might be to imagine that someone, no doubt they exist.
What I was discussing in that post as well as my last one to you was the importance of Unit Tests during INITIAL DEVELOPMENT. The original post used terms like "old architecture" which I took to mean in production.
dojohansen wrote:
It is my OPINION that it is not ALWAYS or AUTOMATICALLY best to develop unit tests PRIOR TO REFACTORING CODE
It's my opinion that it's insane to be in production without unit tests. And no this is not some new belief based on TDD, I learned to use Unit Tests long before I ever heard the term Test Driven Development and long before any frameworks existed, AFAIK. Therefore I was never discussing the merits of developing unit tests based on a need to refactor in post production since the Unit Tests would already exist prior to production. My comments were only to the point of developing unit tests as a standard practice of software development, period. So you can get as upset as you want with what I said, it doesn't change any of that.
led mike
Well it wasn't YOUR thread. Just because you go off on a tangent doesn't mean everyone has to. I tried to write a post relevant to the thread, which was about existing code and refactoring. While it may be "insane" to get into production without unit tests, nevermind that 99.9% of all systems ever developed in the history of the universe has done exactly this, this is irrelevant. You don't get any points for deliberately misunderstanding.
-
Well it wasn't YOUR thread. Just because you go off on a tangent doesn't mean everyone has to. I tried to write a post relevant to the thread, which was about existing code and refactoring. While it may be "insane" to get into production without unit tests, nevermind that 99.9% of all systems ever developed in the history of the universe has done exactly this, this is irrelevant. You don't get any points for deliberately misunderstanding.
dojohansen wrote:
Well it wasn't YOUR thread. Just because you go off on a tangent doesn't mean everyone has to.
YOu replied to me you fucking moron. If you didn't want to talk to me or my point then you could have replied to someone else. What fucking idiot.
dojohansen wrote:
You don't get any points for deliberately misunderstanding.
I have not deliberately misunderstood anything. Sure there is a lot of legacy code that has no unit tests, should you create them? There is no cook book answer to that. Each project is different and therefore must be considered based on it's own unique criteria, period. That said, what's legacy code? In this context, what it means to me is anything I was not an original developer of because I had no control over the creation of unit tests or the design of it, therefore to me it's legacy. If I am developing new code, which includes new modules, classes, libraries whatever for use in legacy systems, I will develop unit tests, period, that's what I have done for the 18 years I have been working in this field and I am not about to stop now just because you come along thinking you know something substantial. You don't, anymore than I do. I didn't develop or discover the concept of unit tests, I was taught to use them by people far more skilled in this field then you or I will ever be.
led mike
-
dojohansen wrote:
Well it wasn't YOUR thread. Just because you go off on a tangent doesn't mean everyone has to.
YOu replied to me you fucking moron. If you didn't want to talk to me or my point then you could have replied to someone else. What fucking idiot.
dojohansen wrote:
You don't get any points for deliberately misunderstanding.
I have not deliberately misunderstood anything. Sure there is a lot of legacy code that has no unit tests, should you create them? There is no cook book answer to that. Each project is different and therefore must be considered based on it's own unique criteria, period. That said, what's legacy code? In this context, what it means to me is anything I was not an original developer of because I had no control over the creation of unit tests or the design of it, therefore to me it's legacy. If I am developing new code, which includes new modules, classes, libraries whatever for use in legacy systems, I will develop unit tests, period, that's what I have done for the 18 years I have been working in this field and I am not about to stop now just because you come along thinking you know something substantial. You don't, anymore than I do. I didn't develop or discover the concept of unit tests, I was taught to use them by people far more skilled in this field then you or I will ever be.
led mike
led mike wrote:
YOu replied to me you f***ing moron.
We're seeing more and more of your true colors I guess. But you see, I was NOT replying just to you. I was replying to anyone involved in or just reading the thread, but since my starting point was a desire to take issue with dogmatic recommandations, not to mention your arrogant "how can there POSSIBLY be ANYONE out there who don't do things your way" attitude I chose to reply to your post.
led mike wrote:
... and I am not about to stop now just because you come along thinking you know something substantial. You don't, anymore than I do.
I'll let those who read decide for themselves. In any case that isn't the issue. And you continue to debate AS IF I have uttered anything even remotely suggesting that one should not use unit tests. I assumed you were DELIBERATELY misunderstanding but I am beginning to doubt if you can control it. Have a nice weekend.
-
led mike wrote:
YOu replied to me you f***ing moron.
We're seeing more and more of your true colors I guess. But you see, I was NOT replying just to you. I was replying to anyone involved in or just reading the thread, but since my starting point was a desire to take issue with dogmatic recommandations, not to mention your arrogant "how can there POSSIBLY be ANYONE out there who don't do things your way" attitude I chose to reply to your post.
led mike wrote:
... and I am not about to stop now just because you come along thinking you know something substantial. You don't, anymore than I do.
I'll let those who read decide for themselves. In any case that isn't the issue. And you continue to debate AS IF I have uttered anything even remotely suggesting that one should not use unit tests. I assumed you were DELIBERATELY misunderstanding but I am beginning to doubt if you can control it. Have a nice weekend.
dojohansen wrote:
AS IF I have uttered anything even remotely suggesting that one should not use unit tests. I assumed you were DELIBERATELY misunderstanding but I am beginning to doubt if you can control it.
No, but I did lose the thread as it has been a long one so, yes, I was wrong, you are correct, you never suggested that, my mistake. We were basically talking about two different things in regards to unit tests and it seems we might actually have similar views on both of them. Therefore it is at least partly my fault, if not completely, that we ended up in a confrontation rather than a discussion.
dojohansen wrote:
Have a nice weekend.
thanks, same to you.
led mike