|
Original? For MQOTD? You don't seem to have caught on to the idea. 
|
|
|
|
|
One Night On An Island
Your time will come, if you let it be right.
|
|
|
|
|
The rain in Spain stays mainly in the plain
Spain is Latin-ish, innit?
Life is too shor
|
|
|
|
|
Qua te movis Tite
.... one of the last things i remember from learning latin 
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
So, the wife found out she is being taken on at her current job (which she loves!) permanently (she's been contract up until now).
To celebrate she went to the local club & played the pokies (fruit machines to you Pommies, One Armed Bandits elsewhere) for a bit.
I usually can't see the appeal, myself.
But she won $2,780 - so all in all not a bad weekend!
PooperPig - Coming Soon
|
|
|
|
|
Damn she had a good week then. Congrats!
New version: WinHeist Version 2.1.0 Beta
Have you ever just looked at someone and knew the wheel was turning but the hamster was dead?
Trying to understand the behavior of some people is like trying to smell the color 9.
I'm not crazy, my reality is just different than yours!
Not my circus not my monkey's!
|
|
|
|
|
PooperPig - Coming Soon
|
|
|
|
|
I'd give you a 5, but quite frankly, you've had enough luck!!
|
|
|
|
|
I'm feeling magnanimous - so I've given you one *
* by which I mean 5
PooperPig - Coming Soon
|
|
|
|
|
You had me at the correct use of magnanimous!!
|
|
|
|
|
If you were a Japanese rodent cartoon character I would have used Manganimouse 
PooperPig - Coming Soon
|
|
|
|
|
I was considering giving him a 5, but I think you deserve it more.
Some men are born mediocre, some men achieve mediocrity, and some men have mediocrity thrust upon them.
|
|
|
|
|
_Maxxx_ wrote: But she won $2,780 - so all in all not a bad weekend!
So now you can afford to come down to my birthday party on 15-11-2014. Going to The Beer Factory this Sunday to make the keg of beer.
Making their imitation Big Rock Traditional Ale (6.0%) and won't be bottling it this year, getting the tap setup in a Sulo Bin so we can pull them fresh as we go.
Michael Martin
Australia
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible."
- Mr.Prakash One Fine Saturday. 24/04/2004
|
|
|
|
|
That is why I hate VS2013, and don't give me that crap about public interfaces only should be unit tested. That's just some crap a lazy IDE developer team pulled out of arse so they wouldn't have to support accessor methods going forward. 
|
|
|
|
|
Like making sure your car's paint is polished, the wheels are ok and have just the right pressure, the doors lock and don't leak rain water and the exhaust does not hang on the floor.
But check the engine? What for? It's not public.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
|
|
|
|
|
There's mechanics for that. 
|
|
|
|
|
CDP1802 wrote: But check the engine? What for? It's not public.
But for your car to work, your engine has to work, doesn't it?
Ergo, if your car (public method or rather application's overall behavior) is working as expected, your engine (private method) is working properly, although there are times when you explicitly have to test it as well.
*OK, hit me.
Your time will come, if you let it be right.
|
|
|
|
|
CDP1802 wrote: But check the engine? What for? It's not public.
Exactly.
The tests you perform are:
Check the lights
Check the engine starts
Check the Oil
Check the steering works
If all that works, and you drive off to work, then all is well with the world.
You could, if you wanted, strip down the engine after every drive, check the spark plug tolerances, check the compression etc. etc. etc.
But as each of these things is essentially tested when the engine starts and the car drives as anticipated, there's no need to do so.
Of course, you should probably have the car serviced every so often, when some of these things will need to be checked - but at the level of the mechanic rather than the driver, these are public methods.
PooperPig - Coming Soon
|
|
|
|
|
The ironic thing is that the "units" are usually the private methods, and the public ones are usually compositions of the private, "unit" methods. The whole point (stating the obvious) is that you want to test the units, which (supposedly) guarantees that composition with those units will work.
So yeah, unit testing using public interfaces is turning the whole process upside down. As usual, even a little thought about the issue seems to be beyond the capability of our beloved tool makers.
Marc
|
|
|
|
|
But Shirley in almost all cases, once developed, one doesn't care what the results of a private method are - one only cares what the results of public methods are.
If a public method calls zero or more private methods to produce an outcome, changes to any of those private methods don't matter, as long as the results of the public method remain unchanged.
What's the point of testing a private method that is used by a public method? It just means the private method gets tested twice.
Although... if the private method accesses (e.g.) the database and so needs to be mocked, then it never gets tested - but then should one test such methods at all in a TDD environment (as it involves setting up and tearing down a whole database)...
** I'm not particularly arguing for one case or the other - more asking out of my poor understanding of TDD, which I'm not really practising in my current role.
PooperPig - Coming Soon
|
|
|
|
|
_Maxxx_ wrote: one only cares what the results of public methods are.
True, because you have faith that the private parts (no pun intended) are doing their job correctly.
_Maxxx_ wrote: If a public method calls zero or more private methods to produce an outcome, changes to any of those private methods don't matter, as long as the results of the public method remain unchanged.
OK, sure, there are public methods that need testing too, and yes, you can make everything public, but the point of private functions is to do, well, private stuff. So, if you have public functions that don't call any private functions, I would suggest that you delete those private functions as they are wasting space.
_Maxxx_ wrote: What's the point of testing a private method that is used by a public method? It just means the private method gets tested twice.
That's not what I said. A good unit test engine needs to provide the ability to test the private functions, through reflection. In all likelihood (and certainly my experience) the public functions aren't worth testing.
_Maxxx_ wrote: Although... if the private method accesses (e.g.) the database and so needs to be mocked, then it never gets tested - but then should one test such methods at all in a TDD environment (as it involves setting up and tearing down a whole database)...
A database interface is particularly annoying to test for the reason you stated. However, if you need to use a mocking framework to test functions that rely on the database, you've designed your code wrong. The DAL should be easily simulated by instantiating a simulation rather than some complicated mocking system. In other words, if you architect your code correctly, you don't need overly complex unit testing solutions.
I'm also not an advocate of TDD. Sometimes I write the code, walk it through the debugger, and I'm done. Othertimes, I write unit tests because I want regression testing for complicated stuff that might need bug fixes my test coverage doesn't handle. I actually never "write the test first." I find it a waste of time. I know a lot of people that get their jollies seeing little red indicators turn green when they write the implementation. Me, I think most of those tests are utterly pointless.
TDD should be used judiciously. I'll give you an example. I am in the middle of writing a SQL generator for CRUD operations on weird database architecture. I decided to first get some core behaviors implemented, like ridiculously simple queries, that I then wrote some tests for to vet out further. While I was writing the code, I made comments about "need to test this scenario" and "TODO: need to handle this condition". Those became good guidance for then writing other tests first that I knew would fail in the existing code, upon which I went back to the existing code and enhanced it (not fixed it) to handle those other conditions. I then repeated the process with other behaviors that I needed:
write a basic process
test it
expand the tests
revise the process
I find that that process works very well for me and keeps me focused on meaningful tests.
And no, I'm not testing unit level functions, I can do that perfectly fine by stepping through them in the debugger. In this case I'm testing the big honking function that glues everything together. However, if I were truly disciplined, I actually would be coding everything in nice small private functions and writing unit tests for those. As it is, there is a "TODO" on my big honking function that says "break this apart into smaller pieces" which I am disciplined enough to do next.
However, another thing that TDD doesn't really talk about is writing experimental code, and the idea of the tests is actually to prove or disprove that what I'm trying to do can be done and that my approach is solid.
Anyways, I'm rambling, but the point is, I see TDD misapplied because programmers don't understand the fundamentals of a good testing practice.
Marc
|
|
|
|
|
I see this as being another case of someone not using the idea of <practice> and saying it doesn't work properly.
(for <practice> you can insert anything from TDD to MVVM to LinqToSQL to whatever).
But I still don't get why you think you need to test individual private methods? Sure, when you are developing you might do bit of R&D in a private method - and you might even write some code just to test it - or run it through the debugger to make sure it's doing what you expect it to do. But the information in that method CANNOT get out without some public method accessing it (and by method I include property) - so it doesn't need a test.
Surely the idea of tests is that they can be run whenever a change is made and reassure you that you haven't broken anything.
Marc Clifton wrote: And no, I'm not testing unit level functions, I can do that perfectly fine by stepping through them in the debugger.
But what happens when another developer in 6 months changes something in one of these methods that then causes all hell to break loose? The hell breaking looses does not necessarily occur in the method he has changed - so even if he steps through his method in the debugger, nothing will appear strange, but that method may be used from hundreds of other places, each with different needs - and stepping through in debug mode just isn't practical in this case; even identifying every path would be a nightmare...
Bottom line, I think, is that if you are going to use TDD at all, you need to design your software in a way that enables its use for all public methods, and for every possible use of each; Now, when the tests run, you know nothing is broken.
Marc Clifton wrote: The DAL should be easily simulated by instantiating a simulation rather than some complicated mocking system.
Not sure I follow - are you saying that if your service layer returns an object via the database you should create a class that instantiates one of those objects with some test data in it for testing? If so, surely that is exactly what testing frameworks do - by faking up the method call and returning a test object? Or am I missing your meaning?
PooperPig - Coming Soon
|
|
|
|
|
it seems like you are testing the implementation more than the behavior!
making it hard to implement thing a different way!...
|
|
|
|
|
Super Lloyd wrote: it seems like you are testing the implementation more than the behavior!
Correct. Behavior relies on implementation. 
Super Lloyd wrote: making it hard to implement thing a different way!...
Not necessarily. If I change the implementation of a function, it's behavior should still be the same -- given the same inputs, I get the same outputs as before the change.
When you refer to testing the implementation, yes, there is a close coupling between a test and its implementation -- it pretty much needs to be that way, it doesn't matter if you're testing private functions or public ones.
Marc
|
|
|
|
|
At least in case of .Net:
If you really want to keep some methods away from public but still want to test them with unit tests consider making them internal instead of private. You can then set an assembly attribute to make them visible to your test project (InternalsVisibleToAttribute[^])
Or if you really absolutely want to test private methods: Noone stops you from using reflection and doing just that.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
