Thy testing quantity of thine units and code...
-
For all my brothers and sisters that do unit test. How many unit tests do y'all have for say a typical sized project of say ~100 files? For my personal smaller projects, I can easily have hundreds of tests. Like I got 45 tests just in one file alone I just wrote that has three utility routines in it. As the project grows that number can easily grow too. For a typical enterprise worthy website or even a polished personal project, that number will _easily_ be anywhere from 2-4K unit tests. Not to mention dozens of functional tests. So, for those of you who embrace the awesome that is testing, how many you typically roll with?
Jeremy Falcon
-
For all my brothers and sisters that do unit test. How many unit tests do y'all have for say a typical sized project of say ~100 files? For my personal smaller projects, I can easily have hundreds of tests. Like I got 45 tests just in one file alone I just wrote that has three utility routines in it. As the project grows that number can easily grow too. For a typical enterprise worthy website or even a polished personal project, that number will _easily_ be anywhere from 2-4K unit tests. Not to mention dozens of functional tests. So, for those of you who embrace the awesome that is testing, how many you typically roll with?
Jeremy Falcon
Jeremy Falcon wrote:
enterprise worthy website
I won't touch those, as you know. I go with "enough until proved otherwise", but I don't use any testing frameworks, which is what you may be thinking.
-
Jeremy Falcon wrote:
enterprise worthy website
I won't touch those, as you know. I go with "enough until proved otherwise", but I don't use any testing frameworks, which is what you may be thinking.
PIEBALDconsult wrote:
I won't touch those, as you know.
Not sure I follow, you won't touch an enterprise website or unit tests?
PIEBALDconsult wrote:
I go with "enough until proved otherwise", but I don't use any testing frameworks, which is what you may be thinking.
That's why I limited the scope. Don't really need another "I don't like it because just don't like it but I can't admit that so I'll diss it" type posts. Just saying man, you'll never convince me unit testing isn't warranted in mission critical software. Some people will never do it because it takes more work and nothing I say is gonna make them change or put more effort into their work. Thus, the question was directed at those who do unit test.
Jeremy Falcon
-
PIEBALDconsult wrote:
I won't touch those, as you know.
Not sure I follow, you won't touch an enterprise website or unit tests?
PIEBALDconsult wrote:
I go with "enough until proved otherwise", but I don't use any testing frameworks, which is what you may be thinking.
That's why I limited the scope. Don't really need another "I don't like it because just don't like it but I can't admit that so I'll diss it" type posts. Just saying man, you'll never convince me unit testing isn't warranted in mission critical software. Some people will never do it because it takes more work and nothing I say is gonna make them change or put more effort into their work. Thus, the question was directed at those who do unit test.
Jeremy Falcon
I unit and integration test etc., of course, but not with a testing framework.
-
I unit and integration test etc., of course, but not with a testing framework.
Well, sorry if I'm sounding jaded, but it's because I am. :laugh: I've spent my life online arguing with peeps who do nothing but hate, argue, are just miserable, barely educated, arrogant, and have absolutely no experience with the topic being argued about, etc. Ironically, I've become miserable in the process of not liking miserable. :laugh: Not sure why you wouldn't use a framework though, but I'll just say cool so I'm not the antithesis of unit testing bashers. :laugh:
Jeremy Falcon
-
Well, sorry if I'm sounding jaded, but it's because I am. :laugh: I've spent my life online arguing with peeps who do nothing but hate, argue, are just miserable, barely educated, arrogant, and have absolutely no experience with the topic being argued about, etc. Ironically, I've become miserable in the process of not liking miserable. :laugh: Not sure why you wouldn't use a framework though, but I'll just say cool so I'm not the antithesis of unit testing bashers. :laugh:
Jeremy Falcon
I can understand that. Though I've never heard of anyone recommending against using testing frameworks. I've definitely seen some with the attitude that if you're not using a unit testing framework then you're not testing at all, and that is simply a ridiculous point of view.
-
I can understand that. Though I've never heard of anyone recommending against using testing frameworks. I've definitely seen some with the attitude that if you're not using a unit testing framework then you're not testing at all, and that is simply a ridiculous point of view.
PIEBALDconsult wrote:
Though I've never heard of anyone recommending against using testing frameworks.
There have been peeps that have, right here on CP even. Seems silly IMO.
PIEBALDconsult wrote:
I've definitely seen some with the attitude that if you're not using a unit testing framework then you're not testing at all, and that is simply a ridiculous point of view.
Well, I'm trying not to turn this into a debate. There's 90% chance any post on CP will be derailed and turned into the same debate we've always had for years. It's just a simple question I asked and yet here we are again in endless debates saying the same thing over and over. It's a waste of time and energy when all I'm trying to do is ask peeps a number. I will say though, there are different levels of testing: unit, functional, integration, regression, user acceptance, etc. And most devs I've talked to that don't unit test don't know the difference. Which makes it hard to trust how much they really know about testing. But, so many of the devs who have no clue will all pretend they know, but those who do know... know who's faking it. For integration and user acceptance, I'd almost say there's credence to your position for a personal project. But for unit and functional you cannot be _repeatably_ deterministic or automate the ability of code breaking from a rogue commit without it. I'll save regressions for another day, but those need to be automated too. Maybe regressions are overkill for a personal project, but definitely not in the enterprise. Clearly we'll have to disagree. I'm not gonna convince you of anything and vice versa. But, out of the two of us, it sounds like I'm the only one with experience on the topic. So, I'm politely saying you are missing out.
Jeremy Falcon
-
For all my brothers and sisters that do unit test. How many unit tests do y'all have for say a typical sized project of say ~100 files? For my personal smaller projects, I can easily have hundreds of tests. Like I got 45 tests just in one file alone I just wrote that has three utility routines in it. As the project grows that number can easily grow too. For a typical enterprise worthy website or even a polished personal project, that number will _easily_ be anywhere from 2-4K unit tests. Not to mention dozens of functional tests. So, for those of you who embrace the awesome that is testing, how many you typically roll with?
Jeremy Falcon
Seems about right. Never counted though, so I looked at a personal project of 100+ files: there are around 250 tests but most tests have multiple assertions, so I'd guess about 500 to 1000 conditions checked. For me, the number of tests grows with time. Almost every bug turns into a test, first to identify it, than to make sure it's quashed.
Mircea
-
Seems about right. Never counted though, so I looked at a personal project of 100+ files: there are around 250 tests but most tests have multiple assertions, so I'd guess about 500 to 1000 conditions checked. For me, the number of tests grows with time. Almost every bug turns into a test, first to identify it, than to make sure it's quashed.
Mircea
Mircea Neacsu wrote:
Never counted though, so I looked at a personal project of 100+ files: there are around 250 tests but most tests have multiple assertions, so I'd guess about 500 to 1000 conditions checked.
Oddly enough, despite me not being a math wizard, I'm a number's nerd. Gotta print them totals for the warm fuzzies. :laugh: Glad to know my findings are on par with yours.
Mircea Neacsu wrote:
For me, the number of tests grows with time. Almost every bug turns into a test, first to identify it, than to make sure it's quashed.
Tru dat man. Tru dat.
Jeremy Falcon
-
For all my brothers and sisters that do unit test. How many unit tests do y'all have for say a typical sized project of say ~100 files? For my personal smaller projects, I can easily have hundreds of tests. Like I got 45 tests just in one file alone I just wrote that has three utility routines in it. As the project grows that number can easily grow too. For a typical enterprise worthy website or even a polished personal project, that number will _easily_ be anywhere from 2-4K unit tests. Not to mention dozens of functional tests. So, for those of you who embrace the awesome that is testing, how many you typically roll with?
Jeremy Falcon
I don't, and I'm very well aware that I should. But, the company I work for is small enough and the software I work on is typically so small scale (relatively speaking) that my boss wouldn't want me to start spending time working on something that is "not code that we ship and will make us money" (and that's pretty much a direct quote). Unless I started to regularly write stuff that produces questionable results. I'm not gonna pretend I'm all that and a bag of chips, but my boss and coworkers know that when I'm comfortable enough to say something's done (by my own yardstick), it's generally in pretty good shape and it's rare someone will find any sort of major hole I didn't think of. If I wasn't likely to think of some scenario my code should support, I wouldn't be likely to think about writing a unit test for it anyway. Having said that, I fully realize this is where regression testing would really help ensure I don't forget about something when refactoring week or months after I wrote the code originally. I'm not trying to disagree. If I was working on mission-critical software at a large corporation, I would insist I get to do it. I was just never presented with the circumstances where I could justify the extra time to my boss. From my perspective, it only needs to happen once.
-
I don't, and I'm very well aware that I should. But, the company I work for is small enough and the software I work on is typically so small scale (relatively speaking) that my boss wouldn't want me to start spending time working on something that is "not code that we ship and will make us money" (and that's pretty much a direct quote). Unless I started to regularly write stuff that produces questionable results. I'm not gonna pretend I'm all that and a bag of chips, but my boss and coworkers know that when I'm comfortable enough to say something's done (by my own yardstick), it's generally in pretty good shape and it's rare someone will find any sort of major hole I didn't think of. If I wasn't likely to think of some scenario my code should support, I wouldn't be likely to think about writing a unit test for it anyway. Having said that, I fully realize this is where regression testing would really help ensure I don't forget about something when refactoring week or months after I wrote the code originally. I'm not trying to disagree. If I was working on mission-critical software at a large corporation, I would insist I get to do it. I was just never presented with the circumstances where I could justify the extra time to my boss. From my perspective, it only needs to happen once.
Smaller companies generally don't have much leeway for anything. You might get more freedom at a company, in the sense there are no code reviews, etc. But, they don't have the money for much. That's the tradeoff. What your boss is really saying is, he doesn't want you learning on the job because they don't want to pay for it. They don't know the value in something if you don't tell them. It's a small company - trust me... they don't know. If you learned something on your free time and came to him/her as an expert about the pros/cons it would be a different story. I've been an employer, so I'm not making this up. Also, I've witnessed firsthand where stuff like this happened in a company where the CEO was worried about budget because this was their first time in the tech world (coming from cookie manufacturing). And sure, lousy employers do exist. But, more times than not what is really going on is people lie about timelines and always take longer. Given that, some are tired of hearing anything that would cause more time. It's an endless cycle that never stops unless the devs start estimate honestly. I could go on, but you get the idea. Nobody wants a worse product. Everyone loves initiative from learning something on your own time. It's an easy sell unless the company is almost broke. In which case, you should be looking for another job.
Jeremy Falcon
-
Smaller companies generally don't have much leeway for anything. You might get more freedom at a company, in the sense there are no code reviews, etc. But, they don't have the money for much. That's the tradeoff. What your boss is really saying is, he doesn't want you learning on the job because they don't want to pay for it. They don't know the value in something if you don't tell them. It's a small company - trust me... they don't know. If you learned something on your free time and came to him/her as an expert about the pros/cons it would be a different story. I've been an employer, so I'm not making this up. Also, I've witnessed firsthand where stuff like this happened in a company where the CEO was worried about budget because this was their first time in the tech world (coming from cookie manufacturing). And sure, lousy employers do exist. But, more times than not what is really going on is people lie about timelines and always take longer. Given that, some are tired of hearing anything that would cause more time. It's an endless cycle that never stops unless the devs start estimate honestly. I could go on, but you get the idea. Nobody wants a worse product. Everyone loves initiative from learning something on your own time. It's an easy sell unless the company is almost broke. In which case, you should be looking for another job.
Jeremy Falcon
We're *totally* on the same page. My boss is already getting plenty of skillset from my part that I've learned on my own. I'm not gonna go out of my way to add to the pile with that one. Besides, I suspect that with unit testing, the most significant time investment isn't going to be me learning it - it's going to be implementing (and then maintaining) them. As for looking for another job - I like the one I have right now enough; for 17+ years I've had the perk of working from home 100% of the time. At this point I could be more easily talked into retirement than another job. :-)