Noobeview

Google it, and you are bound to find places where function overloading is cited as an example of polymorphism. But does being able to not name your methods differently for different argument sets really qualify as one of the 3 fundamental OOP principles? Is going from void FeedCookie(Cookie inputCookie); void FeedMeat(Meat inputMeat); to void Feed(Cookie inputCookie); void Feed(Meat inputMeat); really something that you can't do OOP without? It isn't, in fact there are cases where trying to save a bit of time with this can backfire. Just go for the proper answer: interfaces are polymorphism, because signatures are the same but the underlying methods can be completely different. And you really can't do OOP without them.

I prefer working alone, without all those distracting "colleagues". Why can't I work from my cabin in the woods? Why are they forcing me to work in a team of peons who question my wisdom??? Plenty of people prefer to work alone. However, working in a team is simply more efficient, even if your tasks are not closely related. This is called the synergy effect - a team doing better than the same number of people separately. Two reasons for this should be obvious even to someone who knows jack about psychology such as myself: Truth is born in arguments - it is impossible to be right every time and teammates will usually see things you have missed, even if you supposedly know more than they do; Knowledge use and sharing - people know different things, sharing knowledge and helping others when your knowledge is required for their tasks makes everyone do better. So if someone asks you this, the correct answer would probably be: I prefer to work in teams because team...

If we go googling, we will eventually see that: Data Driven Testing (DDT) - test data is "independent" from code; Keyword Driven Testing (KDT) - test steps and test data are "independent" from code; Behaviour Driven Testing (BDT) - cool business oriented syntax! Engage your shareholders!! Best approach since sliced bread!!! When you actually write the definitions back to back you can clearly see that any KDT framework is also DDT, and any BDT is also KDT and DDT. So what separates BDT from KDT? The cool syntax (given-when-then), which is usually the first thing mentioned, doesn't actually do much. If you transform your keyword from <user clicks button> to <when jimmy clicks the button>, you will not actually add any value. BDT has two closely related features that both give the same benefit - test cases are more readable and more maintainable. You could say it's the OOP of test automation if you were feeling generous. The first...