Tag Info

New answers tagged

2

You should not be so harsh about the term "unit test" when speaking with your colleagues. Many people use this term in a wrong way, for each and every kind of automatic test which can be executed through an xUnit tool, but does it really matter? What matters is not actually how you call these tests, but that you have a common understanding in your team ...


-4

A Unit test should always check, if a question/operation u ask/tell the code, does what was expected. Example: Question - What is x divided by y? Valid unit tests would be: Does the code handle y = 0 correct? (Exception, Return Value, ...) Does the code handle if x/y = > result Data Type ... Not Valid unit tests would be: Does the code even get ...


1

Unit testing is (as far as I've always understood it) writing code to test that the code you have written performs each and every function as expected. In essence it is the 'code that tests the code'. You should explain to your colleague that unit testing is different from functionality testing and also from usability testing. Testing whether your solution ...


2

I find it extremely rare that one would need to mock the methods of a utility class. A very important OOP principle is that state is represented by objects, and that dictates that static methods - which don't operate on an object - should be stateless. You don't need to mock functionality. If you are testing code that depends on your factorial ...


5

I'm all for fighting fire with fire, but turning bad code (lots of static methods) into other bad code (lots of singletons) doesn't sound like such a good idea to spend time on really. From what you have written, this is all in a legacy code context, but you do have change access to the source where those static methods reside (maybe all, but the rest is ...


1

Like you unit test all external resources: You mock them. Write a mock that returns the data you need for your tests (or maybe throws the errors you need for your tests) and then you unit-test your units.


6

Here's a question: does this look like DI? public class MyCar { private IEngine _engine; public MyCar(IEngine engine) { _engine = engine; } public MyCar() : this(new MyV8Engine()) { } } It should, because it IS DI. Dependency Injection is about injecting a dependency into an object, instead of placing the ...


1

If there are objects being instantiated on the action due to lack of contructor injection how can you mock them to test? You can refactor your code to encapsulate all code that should be mocked away into a seperate protected methods and then use partial-mocks to replace that logic. Example (in java) Original protected void moveFiles(File[] ...


-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

Usally Unit-Tests are included in the Project, typically under a different source-folder e.g. src ==> for your Code test ==> for your Unit-Tests. If you use Maven, you will get a structure similar to that. Those tests can be run per Command line and from Eclipse ot-of-the-box, if the Tests are JUnit-Tests. Eclipse has a nice GUI for that, afaik its ...


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


1

The more modern approach is to utilize the HTML Agility Pack. The syntax is closer to the dom selections that would be in a JS Library like JQuery. Here's some examples: http://stackoverflow.com/questions/846994/how-to-use-html-agility-pack http://htmlagilitypack.codeplex.com/wikipage?title=Examples This can also be loaded as a Nuget package.


4

I do not see why mocks would violate the open/closed principle. If you could explain to us why you think they might, then we may be able to alleviate your concerns. The only disadvantage of stubs that I can think of is that they generally require more work to write than mocks, since each one of them is actually an alternative implementation of a dependent ...


2

I think the issue may arise from the assumption that the only valid tests are those which meet the open/closed test. It is easy to see that the only testing that should matter is that which tests the interface. However, in reality, it is often more effective to test that interface by testing the inner workings. For example, it is nearly impossible to test ...


9

The Open/Closed principle is mostly about being able to change the behavior of a class without modifying it. Therefore, injecting a mocked component dependency inside a class under test does not violate it. The problem with test doubles (mock/stub) is that you basically make arbitrary assumptions regarding how the class under test interacts with its ...


6

Note: I'm assuming you are defining Mock to mean "a class with no implementation, just something you can monitor" and Stub to be "partial mock, a.k.a. uses some of the real behavior of the implemented class", as per this Stack Overflow question. I'm not sure why you think that the consensus is to use stubs, for example it's just the opposite in the Mockito ...


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

Public properties and methods define an interface, a kind of contract on how the object is intended to be used. Non-public properties and methods are implementation details. You should always test the interface, and never the implementation details. Implementation may change during any refactoring, and your tests would render useless. The interface ...


7

Generally, one would better be judicious about using protected access at all. The reasons for that are laid out in answers to prior questions over here: Why is Clean Code suggesting avoiding protected variables? As for using it the way you think of here - weakening access limitation because it feels like more comfortable to test - it looks like a terribly ...


2

I think you have it backwards - the integration test is the "real" test, testing the system as a whole. But as it is a slow and often difficult to setup, we have unit tests as a stop-gap measure. They test bits in isolation which should give you an indicator that the code will probably work correctly when sent to the integration test. You can write working ...


8

It sort of seems like a test that says, "yes, your production code is actually working when you don't stub or mock things out." That's exactly what it is. Stubs and mocks isolate the infrastructure from your unit tests, which means that your units get tested, but not the infrastructure that you've stubbed out, nor the connections your units make with ...


1

Automated test were created for the programmers benefit, programmers were not created to serve the tests. We have tests to make us more productive and to reduce the number of “issues” customers complain about. So given that you have behaviour oriented unit tests covering all of the cases in each subclass, there is no benefit to the customer of you ...


30

To verify if you have enough tests or not, you can check your code coverage and your branch coverage induced by the tests (maybe by using a coverage tool, maybe manually by reviewing the code paths or by using a debugger). If you come to the conclusion the tests for the subclasses give you a high enough coverage for your base classes code, then adding ...



Top 50 recent answers are included