4 ms·

Wow so much fail. Where do these mickeymouse programmers repeatedly spring up? "Oh, I'm a supermanprogrammer and I can get it just right the first time because

Wow so much fail. Where do these mickeymouse programmers repeatedly spring up? "Oh, I'm a supermanprogrammer and I can get it just right the first time because I use my brain!" Sure I believe that there are people who can do this and get the code right by just thinking it through. But I have a question for even these people (and their organizations). - What happens when these people leave and the new junior dev becomes the maintainer? - What happens when the code is migrated/reused somewhere else? - How do you make sure your code works at least the same as it did before after you: * modify it * update some dependent component somewhere, say some open source library that your code uses internally. These have bugs too you know... Simply you don't unless you write the tests. The real value of testing (unit testing, regression testing, system testing) comes once you have that nice test suite and you can automate it and make sure that on every change nothing breaks. This is a beautiful thing to have, because simply no human can understand these software systems fully to make sure that some innocent looking change doesn't break something. These things unfortunately happen. Sure testing is hard if you make it so. I said before that I get an average ratio of about 2/5 of actual code/unit testing code. This doesn't mean that "this is so bothersome let's not do it", what it should mean is that you design your system with testability in mind. A primary architectural goal in any design should be testability How easy it is to write unit tests for your classes and methods. The easier it is, the smoother the unit tests are to write and maintain and the better code quality you will have in the end. Also note that when you design your software to be testable you get a few other abilities for free such as reusability. One of the most important starting points is to find the right separation of truly orthogonal components and define their interfaces right. Way too often I see code where the engineer didn't understand this and clumped several unrelated concepts together. This really makes the testing hard and painful.

Const-me 10y ago
> the new junior dev becomes the maintainer this shouldn’t happen. Maintaining a complex project is the job for a senior developer. > What happens when the code is migrated/reused somewhere else someone else need to carefully test what’s he/she reusing. > The real value of testing comes once you have that nice test suite and you can automate it Sure there’s _some_ value, especially for dynamic languages and/or for developers who don’t use asserts and other runtime checks. But that value isn’t free. Not only they’re expensive to develop, they also make very expensive to change things: you change a minor thing in the code, and suddenly dozens of tests are broken. If your code is implementing some 25-years old spec that’s not going to change for another 40 years, unit testing will likely pay off. If you’re creating something new and rapidly changing, using a statically-typed language that you know how to use correctly, and you understand the value of asserts — unit tests are IMO waste of time.
- ensiferum 10y ago
  >>this shouldn’t happen. Maintaining a complex project is the job for a senior developer. Oh but it happens. Even the other senior dev might not be a superman of similar competence. >> someone else need to carefully test what’s he/she reusing. Sure. Oh...look there's a unicorn! >>But that value isn’t free. So that's your excuse for bad code quality? >>Not only they’re expensive to develop, they also make very expensive to change things: you change a minor thing in the code, and suddenly dozens of tests are broken. Sounds like bad orthogonality again. If i don't make any interface changes my tests continue to run as expected. Even with interface changes it comes down to design again. With bad starwars/spiderweb design with lots of coupling it gets harder. Which is my main point. You have to think this through starting at the design level.
  - Const-me 10y ago
    > the other senior dev might not be a superman of similar competence Superman? Any experienced developer should be able to work with other people’s code. If you can’t, you’re either inexperienced, or need to learn the language/frameworks used. > look there's a unicorn! IMO 70% of third-party code is crap, regardless on unit tests. Moreover, nearly 100% of the third-party libraries comes with a license saying “provided as is, without warranty of any kind” or similar. When using any third-party code, you have to carefully test whether it fits your particular purpose. You’ll need to test that code as a part of your system, feeding your data, and measuring the performance characteristics you need. Unit tests don’t help with that. > You have to think this through starting at the design level. Waterfall model only works if you’re building a space shuttle or similar. Architect isn’t a prophet. Design changes through development as requirements change. Between major versions, they can change dramatically. Also there’re external factors that often affect your design: language, it’s runtime, host OS, sometimes even CPU architecture — they all change. Eventually, you gonna need to update your design even if at the time of your version 1.0 it was just flawless.
    - ensiferum 10y ago
      >> Superman? Any experienced developer should be able to work with other people’s code. If you can’t, you’re either inexperienced, or need to learn the language/frameworks used. You'd think so, but thats not always the case. There are many boundary cases and "gotchas" that might not be even visible in the code. (I.e. the stuff that isn't there). Secondly the follow-up dev might be not that interested in code quality. Personally I even feel that if the code doesn't have unit tests in the first place the original developer didn't care and the shop didn't care then why should I bother? >> Unit tests don’t help with that. Ofc they do. If I write a class that uses for example boost.filesystem, and I have my unit tests that test my class. I upgrade my copy of boost. Ofc, my unit tests won't tell me that some other part of boost.filesystem has regressed but at least if some API that I'm using has changed and behaves differently I have a chance of catching it. >> Waterfall model only works if you’re building a space shuttle or similar. Nobody said anything about a waterfall. >> Eventually, you gonna need to update your design even if at the time of your version 1.0 it was just flawless. Personally I don't rush to write the unit test immediately, but only after I've put a bit more code together and verified that the design works. Call it a gut feeling or intuition. But once it's stable I write the unit tests. That doesn't mean that I'd ignore the "testability" aspect when I do the design. Quite the opposite it's an important aspect of the whole process.

Const-me 10y ago

> the new junior dev becomes the maintainer this shouldn’t happen. Maintaining a complex project is the job for a senior developer. > What happens when the code is migrated/reused somewhere else someone else need to carefully test what’s he/she reusing. > The real value of testing comes once you have that nice test suite and you can automate it Sure there’s _some_ value, especially for dynamic languages and/or for developers who don’t use asserts and other runtime checks. But that value isn’t free. Not only they’re expensive to develop, they also make very expensive to change things: you change a minor thing in the code, and suddenly dozens of tests are broken. If your code is implementing some 25-years old spec that’s not going to change for another 40 years, unit testing will likely pay off. If you’re creating something new and rapidly changing, using a statically-typed language that you know how to use correctly, and you understand the value of asserts — unit tests are IMO waste of time.

ensiferum 10y ago
>>this shouldn’t happen. Maintaining a complex project is the job for a senior developer. Oh but it happens. Even the other senior dev might not be a superman of similar competence. >> someone else need to carefully test what’s he/she reusing. Sure. Oh...look there's a unicorn! >>But that value isn’t free. So that's your excuse for bad code quality? >>Not only they’re expensive to develop, they also make very expensive to change things: you change a minor thing in the code, and suddenly dozens of tests are broken. Sounds like bad orthogonality again. If i don't make any interface changes my tests continue to run as expected. Even with interface changes it comes down to design again. With bad starwars/spiderweb design with lots of coupling it gets harder. Which is my main point. You have to think this through starting at the design level.
- Const-me 10y ago
  > the other senior dev might not be a superman of similar competence Superman? Any experienced developer should be able to work with other people’s code. If you can’t, you’re either inexperienced, or need to learn the language/frameworks used. > look there's a unicorn! IMO 70% of third-party code is crap, regardless on unit tests. Moreover, nearly 100% of the third-party libraries comes with a license saying “provided as is, without warranty of any kind” or similar. When using any third-party code, you have to carefully test whether it fits your particular purpose. You’ll need to test that code as a part of your system, feeding your data, and measuring the performance characteristics you need. Unit tests don’t help with that. > You have to think this through starting at the design level. Waterfall model only works if you’re building a space shuttle or similar. Architect isn’t a prophet. Design changes through development as requirements change. Between major versions, they can change dramatically. Also there’re external factors that often affect your design: language, it’s runtime, host OS, sometimes even CPU architecture — they all change. Eventually, you gonna need to update your design even if at the time of your version 1.0 it was just flawless.
  - ensiferum 10y ago
    >> Superman? Any experienced developer should be able to work with other people’s code. If you can’t, you’re either inexperienced, or need to learn the language/frameworks used. You'd think so, but thats not always the case. There are many boundary cases and "gotchas" that might not be even visible in the code. (I.e. the stuff that isn't there). Secondly the follow-up dev might be not that interested in code quality. Personally I even feel that if the code doesn't have unit tests in the first place the original developer didn't care and the shop didn't care then why should I bother? >> Unit tests don’t help with that. Ofc they do. If I write a class that uses for example boost.filesystem, and I have my unit tests that test my class. I upgrade my copy of boost. Ofc, my unit tests won't tell me that some other part of boost.filesystem has regressed but at least if some API that I'm using has changed and behaves differently I have a chance of catching it. >> Waterfall model only works if you’re building a space shuttle or similar. Nobody said anything about a waterfall. >> Eventually, you gonna need to update your design even if at the time of your version 1.0 it was just flawless. Personally I don't rush to write the unit test immediately, but only after I've put a bit more code together and verified that the design works. Call it a gut feeling or intuition. But once it's stable I write the unit tests. That doesn't mean that I'd ignore the "testability" aspect when I do the design. Quite the opposite it's an important aspect of the whole process.