Tag Info

Hot answers tagged

76

Regression testing It's all about regression testing. Imagine the next developer looking at your method and noticing that you are using magical numbers. He was told that magical numbers are evil, so he creates two constants, one for the number two, the other one for the number three—there is nothing wrong in doing this change; it's not like he was ...


43

Because nothing is so simple that there can't be bugs. Your code, while on the face of it looks to be bug free. It is in fact a simple programmatic representation of a polynomial function. Except it has a bug... public function polynominal($a, $b, $c, $d) { return $a * pow($x, 3) + $b * pow($x, 2) + $c * $x + $d; } $x is not defined as an input to ...


20

Yes. If we could say with 100% confidence, with certainty: this function will never be edited and will never run in a context which could cause it to fail - if we could say that, we could drop the tests and save a few milliseconds on every CI build. But we can't. Or, we can't with many functions. And it's simpler to have a rule of running all the tests ...


12

Everything said in the other answers is correct, but I will add one more. Documentation Unit tests, if well written, can explain to a developer exactly what a function does, what its input/output expectations are, and more importantly, what behavior can be expected of it. It can make spotting a bug easier and lower confusion. Not everybody remembers ...


8

Test coverage is good. 100% test coverage is absolutely reachable without insane amounts of effort[1], except of course for those this-can-never-happen-but-lets-check-for-it-nevertheless assertions. [1]: assuming reasonably testable code Especially when talking about error handlers, these have to be covered by tests. The “happy path” will be implicitly ...


7

When you refactor a class without changing it's API, you want your unit tests to make sure you do not break anything during the refactoring. So you obviously don't want to change your existing unit tests on PersonComponent before the refactoring is complete. The interesting question is: is it a good idea to change the tests afterwards, to make it possible ...


6

Do not do this Sleeps are unpredictable. You never know when your test environment happens to be downloading Windows Updates when the virusscanner runs and the timeout happens to be a second too short. Your tests will become brittle and useless because you'll have to run every failed scenario multiple times to make sure it was an actual failure. And sleeps ...


2

Reality Check I have been in challenging environments where testing is "a waste of time" during budgeting and schedule, and then "a fundamental part of quality assurance" once the customer is dealing with bugs, so my opinion is more fluid than others might be. You have a budget. Your job is to get the best product you can on that budget, for whatever ...


1

it is a HUGE program I would probably start with priorities. An easy tool is the priority matrix with Importance x Test-Effort (start simple first) or Urgency. It gets you a starting point and helps spending your time/money more strategically. You could use a whiteboard and sticky notes while brainstorming with a collegue/domain expert. ...


1

It seems like you have a good idea of how the program should work and for expected input it works correctly. (make sure there are tests for this) but given the size of the program you can't be certain that edge cases (unexpected input) won't break it. In fuzz testing you take parameters that produce a known output and you randomly change a parameter. you ...


1

Sure, rapid prototyping can lead to frequent changes on your APIs for a duration of time, but I will expect changes to eventually mature and stabilize after requirements fall into place and you can essentially do an 'API freeze'. If you are making changes to undo past changes, then you may be getting ahead of yourself and straying away from the You Aren't ...


1

Your application code and your EDMX should be portable, i.e. you should not need to change either of them when moving between Environments. That means no database (or schema) names "hard-coded" in there or, if there are, you should be able to replace them using nothing more complex than a global Search-and-Replace. Anything "cleverer" and all bets are off. ...


1

I agree with Snowman, but as to not leave you empty handed, I will discuss a few possibilities. If by 'doing the front-end work', you have primarily been tasked with designing the project, then you can design the site according to your normal workflow and simply pass it off to him to integrate it. If you are responsible for everything client-side, then you ...


1

It seems like a fairly classical testing scenario. The solution is to test both the ebay abstraction by integration testing against ebay. You don't want to do this everywhere as it will slow down all your tests so keep it to a minimum. When you are fairly sure that the abstraction works you can replace it with a mock when testing the rest of your code. Then ...



Only top voted, non community-wiki answers of a minimum length are eligible