Tag Info

New answers tagged

0

Are the four methods - and the data returned - dependent upon, and related to, each other? If there is no real dependency, then expose those methods as public ones and allow each to return a smaller set of data, which can be independently tested. If there is a strong dependency, consider making your large object hierarchical. So it may have four fields, ...


1

Refactor the 4 other methods into a separate class (could be one class per method, or one class with 4 methods). Chances are the class that is creating the one big object has too many responsibilities and you should split those up. Test the individual methods to confirm that they work. The result of those calls will be a lot smaller than the big object. ...


0

Personally, for each package I have one _test.go file with several test functions in (they must take the form func TestX(t *testing.T)). Each of these test functions runs through all of my regular functions in the package, passing in acceptable data, extreme data (data on the boundaries of acceptable), and invalid data (passing nil in, etc.). I then test ...


0

Selenium IDE allows you to walk through a scenario and add assertions to check it works as expected. which you can then save as a file you can play back later. It does have a few limitations. the extension only works in firefox. checking for visual changes may be difficult. ( it looks like you can check css properties )


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

In TDD fashion, you refactor your tests along with your code. First you are supposed to change your test, then your code. But try to ensure you have only 1 or few tests failing at a time. To accomplish, you might end up in an intermediate state, that won't exit in final code.


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 ...


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 ...


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 ...


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. ...


-2

Developer Documentation How do I (as another developer) know that this has been tested? If I want to fix a bug in the self contained function, how do I know that I am not introducing a bug that you had already considered? Complexity indicator: # of tests can be a good measure of how complex something is. This may indicate that you shouldn't touch it ...


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 ...


0

Yes, keep the tests, keep them running and keep them passing. Unit tests are there to protect you (and others) from yourself (and themselves). Why is keeping the tests a good idea; Validate the previous requirements' functionality in the face of new requirements and additional functionality Verify that refactoring exercises are correct Internal ...


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 ...


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 ...


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 ...


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 ...


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 ...


-3

Simply, Testing means, finding the inputs that cause a Software to fail while debugging is the process of finding the fault of a given failure.


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 ...



Top 50 recent answers are included