|
TheOnlyRealTodd wrote: Any advice/resources on this would be super helpful.
You posted a lot of code in the Lounge.
You're welcome 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
TheOnlyRealTodd wrote: and I'm finding strange, inconsistent, and bizarre things happening in my thought processes and code in some ways as well. Is this pretty normal when you first try to learn TDD?
Yes. TDD is for the birds, but even they didn't first write tests to figure out if wings could support them, and then developed their wings.
In other words, TDD is ridiculous, because it requires that you write code to test something you haven't written yet.
The mindset for writing tests is orthogonal to writing the code you are going to test. When you do the latter, you're thinking about abstraction, decoupling, performance, optimal structures, and, here's the clincher, you're thinking about how to structure the code so it can be tested.
When you're writing the tests, you're thinking about edge cases, parameter validation, exceptions trapping, whether the business logic is correct, and here's the clincher, you're thinking about how to ensure that all code paths are actually exercised.
Now I ask you, how can you test that all code paths are actually tested when you haven't written the code?!?!?!
So of course TDD is a mind f***. It's a different process, and it's usually a BAD process. Of course there are cases where you can write the tests first, but certainly in my experience, anything other than a very isolated piece of business logic, it doesn't make sense. The main result of TDD ends up being that you've written a bunch of useless tests, and even worse, you've written code to meet the structure imposed by the test. That might work fine for play languages, but is usually a bad idea for professional languages. (I'll leave the reader to figure out what I mean by play vs. professional.)
So what should TDD be then, you might ask? Well, it should be a concept of what needs to be tested - is it algorithm correctness, is it performance, is it multithreaded support, is it worth testing? Then write the code with the idea in mind of what you are wanting to test, so that the code is testable, then write the tests.
We'll let the voters decide whether they agree or not. And if they don't, well, the voting is rigged!!!
(Oh, and great question BTW. I love a good opportunity to emote on the idiotic ideas this industry has created.)
Marc
modified 21-Oct-16 20:41pm.
|
|
|
|
|
TDD is extremely good for two things:
0. Getting loose cannon devs on track.
We all know and have to deal with such guys, but it's not hard to write tests with premises like "This is the name of the output module, and these are the expected outputs from it".
-- You know your inputs
-- You don't care what the processes are; that's where you rely on other developers
-- You know the outputs That Have To Result.
So write tests for it.
What TDD does is get that clear in everyone's mind, so flying off in weird and unwanted directions is less likely to happen.
1. Forcing specs
For me, this is their primary function. Even "produce working code" is secondary.
Put it this way: It's a way of introducing specs when the f***ing lazy management team hasn't provided them -- with the added bonus that the f***ing lazy management team has to sign off on it.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: Put it this way: It's a way of introducing specs when the f***ing lazy management team hasn't provided them -- with the added bonus that the f***ing lazy management team has to sign off on it.
Absolutely!
Marc
|
|
|
|
|
Your first test seems weird and unnecessary...
If you decide to overwrite the ToString method (maybe for debugging purposes) your test will fail, while it wouldn't actually fail any business requirement (unless you actually use ToString in your business, but I can advice against that).
Besides, you're using a strong typed language so if you change the type your code wouldn't even compile (let alone run that test)!
If you really want to check the type check it using typeof so that your test doesn't break if you even only rename your class.
In fact, you're testing if a constructor actually constructs, if it wouldn't you'd have bigger problems than that one unit test (because C# just broke)! 
Test only what is important for your business cases. The statistics on the array are important, because you can't have a customer get a wrong average or count of his invoices (or whatever it is you're doing). Testing whether a class has a certain name is not important (save, maybe, for some edge-cases with reflection).
TheOnlyRealTodd wrote: But then I was questioning whether I should even be testing these methods since they are using built-in provided standard library algorithms rather than my own custom algorithms in the first place.
Yes, you should test them.
Test your public methods like you don't know the implementation. In fact, you're testing now to prevent your code from accidentally breaking in the future. Testing it lets you change your implementation in the future without worrying you'll break anything.
Be sure to test with null and empty arrays and rounding errors in your average (especially since it's a floating point type)
I also agree with Marc by the way. Your tests are there for your code and not the other way around. TDD does switch it around though.
I've worked on a project where every method was public so it was testable... Not quite how it should work. It only prevented us from changing implementation details because tests, that didn't affect business requirements, would break.
Good luck with your testing adventures. I still find testing a very difficult subject!
|
|
|
|
|
I spent some time learning it, and then discarded it as being useless for my requirements.
All it did was triple the amount of time it took to develop anything, as I'd simply be writing code to the same requirements twice and then debugging it twice.
Sure, it helps if the requirements are set, but most of the time I have little idea what the final product will look like because the boss doesn't know what he wants either. Sure, I could make a prototype, but if I do that, the boss says 'looks okay, tweak that and that and you're done - I'll expect that by Friday then?'
It also helps when the cost of failure is high. eg. a bank or publicly available software. The cost if my software doesn't work for a few hours? Pretty much nothing unless it screws up so badly as to corrupt the database.
|
|
|
|
|
|
twitter too. 
|
|
|
|
|
Vincent Maverick Durano wrote: twitter too
Did anyone worth talking to notice?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I didn't, question is, was I worth talking to? 
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
Why are you talking to me?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Because Twitter isn't talking to anyone. 
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
Well, I can't fault your logic.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Why would anyone hurt that little blue bird?
|
|
|
|
|
perhaps the aliens find the little blue bird annoying.
|
|
|
|
|
Time to get some tea. ![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
In case you feel like editing your HOSTS file to connect to Github without waiting for this to be resolved:
192.30.253.113 github.com
151.101.32.133 assets-cdn.github.com
151.101.32.133 avatars0.githubusercontent.com
151.101.32.133 avatars1.githubusercontent.com
151.101.32.133 avatars2.githubusercontent.com
151.101.32.133 avatars3.githubusercontent.com
151.101.32.133 avatars4.githubusercontent.com
151.101.32.133 avatars5.githubusercontent.com
|
|
|
|
|
That makes me wonder if that odd thing I saw earlier with CP have to do with this DDoS?
Maybe I was routed through those IPs at that time or something or the cdn.codeproject.com is hosted out there where things were attacked?
I dunno, but interesting.
Isn't this Internet thing supposed be able to be hit by a nuke and survive? Like cockroaches, right? 
|
|
|
|
|
Ah, a true githubber
|
|
|
|
|
Apparently OpenDNS was weathering the storm due to the caching technology they use, it would have been easier probably just to switch your router DNS settings to use OpenDNS addresses for a short term fix, rather than a site-by-site case specific fix in the host tables.
Maybe something to remember for next time...........because there will be a next time. 
|
|
|
|
|
3rd one is ongoing.
https://cybermap.kaspersky.com
|
|
|
|
|
This [^] is why hardware companies should not try and do the software themselves.
Everyone's so keen to wire up their microwave and close their garage door while in the next state.
No one's bothering with a decent padlock. 
cheers
Chris Maunder
|
|
|
|
|
Text messages always look better on my fridge's 3x2" display.
|
|
|
|
|
Right. Plus, those companies have defaulted to WiFi technologies which ends up connecting devices unnecessarily (in many cases) to the Internet. Why didn't they just use _local_ connections like bluetooth enabled type of devices instead?
Some might see my idea as limited, but I have no need to monitor my refrigerator from 50 miles away. I just don't.
And, I like the responsibility of having to know my thermostat is set before I leave the house. Just sayin'.
|
|
|
|
|
Most of the companies are blaming the password. Soon we will have iPasses, and still have the same problems, just with a big added bill.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
