|
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.
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[^]
|
|
|
|
|
A huge difference would be made by, for example, "You cannot use your fridge's IoT functions until you have changed the factory-set username and password" messages.
Yes, usernames and passwords are a PITA, but you can stick them to the fridge door with a fridge magnet -- let's see hackers get at that programmatically.
"We want to make installation easy for our customers" can only go so far.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|