Tag Info

Hot answers tagged

23

There can be value, but this is a bit of a smell. Either your tests aren't well isolated (since test_order really tests two things) or you're being too dogmatic in your testing (making two tests testing the same logical thing). In the example, I would merge the two tests together. Yes, it means you have multiple asserts. Too bad. You're still testing a ...


15

This design is known as Service Locator* and I don't like it. There are lots of arguments against it: Service Locator couples you to your container. Using regular dependency injection (where the constructor spells out the dependencies explicitly) you can straightforwardly replace your container with a different one, or go back to new-expressions. With your ...


8

What you're talking about is called mutation testing, and there are a number of implementations available. I've not tried either, but there are at least two javascript versions: grunt-mutation-testing, and mutandis


6

It's not exactly clear what you are asking. You can always prove a program correct, if you want. This is independent of the language. The question is, can you get the computer to do the proof for you, or at least check a proof given by you? And the answer is: Yes! In fact, the Curry-Howard-Isomorphism states that there is an isomorphism between logic and ...


6

Despite established wisdom in writing unit tests, Martin Fowler has said that his idea of a unit is generally "a bunch of closely related classes and treat them as a single unit. Rarely I might take a subset of methods in a class as a unit." So there's no real reason why you shouldn't be unit testing a couple of tightly related methods as one unit. ...


6

For a heuristic algorithm which is supposed to not return the ideal but a "good enough" solution, you would have various test-cases and check is the solution actually valid? You certainly want to make sure your route-finding algorithm doesn't return paths which are impossible or which don't actually lead from start to finish. You might not be able to prove ...


5

Remove the duplicate test code Having tests on your child-classes for code that is in the parent class means twice the maintenance if the parent class changes. The reason you move to a parent class is specifically to avoid duplicating code, actual code as well as tests. (And if you ever end up creating a third child you might end up thinking that all tests ...


5

The best arguments against the Service Locator anti-pattern are plainly stated by Mark Seemann so I won't go too much into why this is a bad idea - it is a learning journey that you have to take the time to understand for yourself (I also recommend Mark's book). OK so to answer the question - let's re-state your actual problem: So rather than adding ...


4

Command Pattern is generally used to decouple WHAT from WHO, and WHAT from WHEN. This is the benefit of having a simple interface as simple as: public abstract class Command { public abstract void execute(); } Lets imagine that you have a class EngineOnCommand. You can pass this Command to other objects which accept instances of Command. So this means ...


4

Your tests should be explicit. It's not completely inferred that if text_length fails test_order fails. I'm not sure how it goes in Python which you've posted, but if len(result) is 3 then the first will fail but the second may pass (and if not in Python, then in languages like JavaScript for sure). Like you said, you want to test that the function return ...


3

The only value of test_length here is that, if everything passes, its very presence indicates that "length" has been tested. So it's really unnecessary to have both these tests. Keep only test_order but consider renaming it test_length_and_order. Incidentally, I find the use of names that begin with test a bit clumsy. I'm a strong advocate of test ...


3

The size of a project should make no difference whatsoever when doing test driven development. The point of unit testing is that you are testing isolated units of functionality completely independently of other areas of the code. This is achieved by using mocks to fake out the expected behavior of other parts of the program. This can be most easily achieved ...


3

I think that both of the testing method proposed so far are bad. omouse suggest exposing validationRules an internal implementation detail. In doing so, he is suggesting that you test the implementation when you should be testing the interface. See this blog for discussion. The op then proposed returning the number of added rules. But as far as I can tell ...


3

It's important to understand that a single method may not be your "unit". To give a contrived example, if (for some reason) you created a class with public methods: Add(object key, object value); Get(object key); which just wrapped a private Dictionary, it would be inconceivable to test just one of those methods at a time, independent of the other. ...


2

Most of the benefit of commands is that they make it easy to undo an action, redo an action, perform an action in multiple places (over a network connection), or perform it at a later date, and so on. With that in mind: Probably not. It's hard to imagine any situation where "undoing" a dialog box makes sense, and this is the sort of thing I'd rather put ...


2

Some thoughts: The proof doesn't know what you want to accomplish with your code. That's the domain of well-written software requirements. Tests (when used as a description of requirements, as in TDD) are proof of the software requirements, not the software itself. The proof can, and often does, exceed the complexity of the actual program. Proofs, ...


2

You definitely should be unit-testing addErrorRule. You can do this by testing for the side-effects of the addValidationRule call. Make sure there is a validation rule added to the right list (errors, not warnings). Yes, you must expose the validationRules variable to be able to unit-test addErrorRules. Here's example code for how the unit test might look ...


2

Having one instead of many parameters in the constructor is not the problematic part of this design. As long as your IContext class is nothing but a service facade, specificially for providing the dependencies used in MyControllerBase, and not a general service locator used throughout your whole code, that part of your code is IMHO ok. Your first example ...


2

Most optimization algorithms (including heuristics) work on some configurations (in your example a route) by applying operations on them. The operations for itself should guarantee that they deliver only valid configurations, so first there should be unit tests for each of them. When you know for sure the optimization algorithm uses only those operations, ...


1

You can create a new job that only runs your integration tests. I always split up jobs like this: build + unit test deploy into UAT run smoke tests run integration tests / UAT Take a look at the plugins Build Result Trigger, and the new Build Flow Plugin. You can also just trigger another job with plain Jenkins without any plugin. In your job, add a ...


1

I'd leave these tests separate if that is how they've evolved to be. Yes test_order is likely to fail whenever test_length does, but you definitely know why. I'd also agree that if the test_order appeared first and you found a testable failure was that the result was possibly not two values, adding that check as an assert and renaming the test to ...


1

Is the path statically or dynamically generated? If it is dynamic, then you can maybe test for a specific path because there is importance in testing the calculation of the path. I like to reference the same string constants the app uses when possible - that's one way to help. But if it's static, well - what are you really getting by testing? I think then ...


1

You're giving up a lot of static information this way. You're deferring decisions to runtime like many dynamic languages do. That way you loose static verification (safety), documentation and tooling support (auto-complete, refactorings, find usages, data flow). A classic static/dynamic trade-off. I would not do it this way. I don't see why adding ...


1

In order for unit tests to work you have to be able to mock all the external dependencies to your code (otherwise you're doing an integration test). Your problem is you have direct dependencies to your data access implementations. This is coupled with the problem that your handler is both doing it's handling work and is responsible for creating your data ...


1

First, I think it's good to state what's important. I'm familiar with "continuous integration" types of build systems, so I think that 1) Checking in everything necessary to build, 2) Building from a remote system in an automated way to prove #1, and 3) Testing in automated fashion - are all important. If you have different values, you may come to a very ...


1

With these main questions: Is it even useful to automatically generate these testcases at all? Could it be extended to do even more useful things? Does, by chance, such a project already exist and would I be reinventing the wheel? I will boldly claim that yes, generating testcases can be useful and yes, such projects already exist and are used. ...



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