IT/Software career thread: Invert binary trees for dollars.
- Thread starter Traak
- Start date
-
Guest, it's time once again for the massively important and exciting FoH Asshat Tournament!
Go here and give us your nominations!Who's been the biggest Asshat in the last year? Give us your worst ones!
ShakyJake
<Donor>
- 7,960
- 20,071
They keep hounding us to write unit tests, but the problem is our application is so old it's inherently untestable. New stuff we can unit tested, sure, but changes or additions to legacy code? Forget it. Our app is an ASP.NET Web Forms which has so much business logic written into the code behind files it's crazy. There is no way to unit test this crap and I don't think TPTB understand this.
Vinen
God is dead
- 2,791
- 497
This is the exact shit we used to have. HOLY SHIT DO I HATE CODE-BEHIND IN WEB APPS.
Yeah the webservice I'm on is pretty rough to test as well. It was clearly written by someone who knew how to integration test but not unit test atomically. The logic that you want to test is side by side and coupled with the various JMS queues, HBase put, all the persistance stuff and generally required spring-injected XML configuration files. So to test even some basic logic you have to create a full stack mock of an entire backend system.
Vinen
God is dead
- 2,791
- 497
Noodleface
A Mod Real Quick
- 38,359
- 16,249
Thank god for writing BIOS and being able to test it on the actual hardware that goes to the field
Hachima
Molten Core Raider
- 884
- 638
haha, this removes me of a tweet I saw recently for an interview with a new developer.
Q: "Tell me your experience with unit testing."
A: "I haven't been forced to do that yet."
Tuco
I got Tuco'd!
- 47,907
- 82,513
I like doing unit testing for test driven development and write tons of it. I like TDD because instead of deleting your shitty temporary testing harness you use to run your new code you end up with a suite of tests that not only help future validation but also document and demonstrate how your code should be used.
But shit, how many times can you spend days writing comprehensive unit tests for already in-use software before you think, "Guys, more unit testing is not value added work."
But shit, how many times can you spend days writing comprehensive unit tests for already in-use software before you think, "Guys, more unit testing is not value added work."
Cad
scientia potentia est
- 25,818
- 50,660
And what happens when the bug is in the test not in the code its testing? How do you test the test? And what do you use to test the test that tests the first test?
And who updates the tests to follow along with new requirements? If you had time to do that (roughly 100-150% increase in time spent to maintain code + tests) you could probably have just written better code in the first place. And again, nothing is stopping you from coding in bugs to the tests in the first place, making them useless.
And who updates the tests to follow along with new requirements? If you had time to do that (roughly 100-150% increase in time spent to maintain code + tests) you could probably have just written better code in the first place. And again, nothing is stopping you from coding in bugs to the tests in the first place, making them useless.
Because your tests are basically
If your tests are insanely complicated in terms of logic then you've got a problem with correct unit testing. I don't see how anyone can be a competent developer and not see the benefit of unit testing. And for the testing new requirements if the requirement turns out that method b when paramatarized with "c" should now return false that is captured in your unit test as a failing requirement. It also gives you a strong sense of "this still works" when/if you have to perform large rewrite and refactors on a code base.
Cad
scientia potentia est
- 25,818
- 50,660
I guess I don't really write the kind of bugs that testing would catch. Thats easy enough and probably has value, but I'd be afraid someone would just hit those and go "yup it works!" -> production.
If you write code to solve difficult problems unit testing will always find bugs, expose edge cases and give a sense of security for your code does what it needs to do. I have worked in code bases with limited to no unit testing and not only is the code always a nightmare but you don't know if what you're adding or changing modifies existing behavior or not. You will not find any competent developer which will make a case against unit testing. They're just that important. But they're just a facet of the larger testing program to include unit, integration and acceptance.
Khane
Got something right about marriage
- 20,588
- 14,318
It's interesting that so many people think it's an either/or scenario. I want unit testing AND QA.
The best development shop I ever worked for had pair programming, wrote unit tests, had automated daily builds that executed those tests AND had QA staff to test user experience and business edge cases. It was awesome.
Vinen, you can pretend people should be experts on everything they work on but the fact of the matter is you work for a solely technical company that values that technology above all else because it's what they sell. Many of us work in industries that need to leverage technology but don't value that technology enough. We, as developers in those industries, rarely get the chance to become experts in the business side of those industries. It's unrealistic to ask a single person to be an expert on such a wide array of subjects. That's why BAs exist, QA staff, etc etc.
Sometimes you have to rely on the expertise of the BA to write specs you can design around.
The best development shop I ever worked for had pair programming, wrote unit tests, had automated daily builds that executed those tests AND had QA staff to test user experience and business edge cases. It was awesome.
Vinen, you can pretend people should be experts on everything they work on but the fact of the matter is you work for a solely technical company that values that technology above all else because it's what they sell. Many of us work in industries that need to leverage technology but don't value that technology enough. We, as developers in those industries, rarely get the chance to become experts in the business side of those industries. It's unrealistic to ask a single person to be an expert on such a wide array of subjects. That's why BAs exist, QA staff, etc etc.
Sometimes you have to rely on the expertise of the BA to write specs you can design around.
Vinen
God is dead
- 2,791
- 497
I want developers to handle Unit Testing, Integration and Functional testing.
While qe handles System Testing (ex: System Performance, Product integration qualifications (ex: different versions of vSphere)) and other more complex tasks which require additional setup to test).
Tuco
I got Tuco'd!
- 47,907
- 82,513
Yep, these are all big problems that have no easy solutions.
A lot of my unit tests verify mathematical algorithms and some rely on so many mathematical operations that performing the math by hand is infeasible. So I verify qualitatively that the algorithm is working, then set some typical inputs, get the quantitative outputs and use that as my unit test which fails anytime something changes. These are pretty brittle and circular but still useful, especially when changing from say, one linear solver implementation to another.
Lendarios
Trump's Staff
- 19,360
- -17,424
I want a Pony.
In seriousness =) the thing working against becoming an expert is simply time and money. Most developers who work in non tech companies change jobs quite frequently. You basically build something as a contractor, then move on, or depending on the political atmosphere there is no time set aside for testing.
Vinen
God is dead
- 2,791
- 497
And I want developers to do thier job.
I know we can't have everything we want
I'm not saying you need to know the entire product... but you do need to have some level of expertise on what component you are building. Even more so when you go full stack.
Cad
scientia potentia est
- 25,818
- 50,660
I don't think developers need to be subject matter experts. They CAN be, and they probably will be by osmosis once they have worked on that type of product for a while, but your system designers/architects will work with your functional experts to design use cases, UI's, and functional requirements. Those requirements will get turned into modules and system design by your architects. The developers themselves just need to know what their module is supposed to do, and any meta requirements (this needs to be fast, this needs to multithread, etc). Asking your developers to be QA, functional experts, and also expert developers is just stupidity.
My ideal workflow would be your requirements people/architects working on defining the high level requirements for each module, and sketching out what tests those modules should be able to pass, test engineers writing the tests that will define a pass, and the developers coding to the requirements and the tests.
If you're going to have structured tests they need to be written by someone other than the developer. And the developer shouldn't be coming up with requirements himself. The requirements should be written by the functional experts. The reason for this separation is so that when the developer has the wrong idea about how a module should work (or codes a particular type of bug) he won't code that same bug or misconception into the test. In fact, I'd prefer if these 3 teams/people were separated and did not speak to each other so each can come to their own conclusions, and if the conclusions conflict then it can be resolved by the system architect/functional people.
This would result in very high quality code but the manpower would be higher and everyone is cheap so it never works like this.
My ideal workflow would be your requirements people/architects working on defining the high level requirements for each module, and sketching out what tests those modules should be able to pass, test engineers writing the tests that will define a pass, and the developers coding to the requirements and the tests.
If you're going to have structured tests they need to be written by someone other than the developer. And the developer shouldn't be coming up with requirements himself. The requirements should be written by the functional experts. The reason for this separation is so that when the developer has the wrong idea about how a module should work (or codes a particular type of bug) he won't code that same bug or misconception into the test. In fact, I'd prefer if these 3 teams/people were separated and did not speak to each other so each can come to their own conclusions, and if the conclusions conflict then it can be resolved by the system architect/functional people.
This would result in very high quality code but the manpower would be higher and everyone is cheap so it never works like this.
Cad
scientia potentia est
- 25,818
- 50,660
Vinen it seems like what you want is for the grease monkey who works on your car to be an expert automotive engineer and tester in addition to being a guy who turns wrenches and replaces alternators. The guy who turns wrenches does not need to know the chassis design of the vehicle or why a particular spring rate was chosen. He just knows from the book that these springs go on this car. This alternator model goes on this car. This size piston fits if we bore 2 over. He turns fucking wrenches.
Your "average" developer is a code monkey that will work best if you can give him detailed requirements and let him do his thing. If you want him to do 5 different jobs he's going to suck at all of them.
Your "average" developer is a code monkey that will work best if you can give him detailed requirements and let him do his thing. If you want him to do 5 different jobs he's going to suck at all of them.