Tag Info

New answers tagged

3

Absolute nonsense. A few thoughts: You should not take OOP and it's principles too seriously. Many times functional or other software paradigms make more sense. Though the objects thing is cool... thinking in concrete components and all that. Testing, and specifically Unit Testing is meant to serve the project, verify it's design, and assure its ...


3

If that common behavior sees frequent use, it will admittedly be executed multiple times during tests for each of the subclasses, but so will it at runtime in production, there's nothing wrong with it. However, that doesn't mean you should specifically test the common logic multiple times. Concrete/abstract superclass If the superclass is not abstract and ...


1

You stumbled on one of the Bigger problems that tends to get swept under the rug in unit testing/TDD discussions. Well designed code from an object oriented perspective is generally hard to unit test, code that is easy to write unit tests for usually is compromising some paradigms of object oriented design. Most approaches to unit testing tend to drive ...


0

What isn't clear to me is where should these objects be created Anywhere except in the dependent object itself, obviously. The point is that the consumer object doesn't control its dependency's lifecycle, someone else does. One possible global approach to this is to compose the entire application's object graph in a single place, the Composition Root, ...


1

Most likely those objects are created from a factory or from a single point where the object graph is created as indicated from @guillaume31 comments. If from factory it would look something like this: namespace Repository.Lookup { public class LookupRepositoryFactory { public static ILookupRepository Create() { ...


2

I don't know ASP.NET, but generally your dependencies would be on interfaces, and in your unit tests you provide mock, stub, or fake implementations of those interfaces. This lets you test your class in isolation, since the only code under test is the class itself plus your "skeleton" dependencies.


3

Ideally, you want both unit tests (which test individual functions) and integration tests (which test all the functions together), not just one or the other. You will also need a way to mock out the web service you're calling so that these tests don't depend on it. To directly address a few of the sub-questions: So is correct to create a big test that ...


1

Two things could help you there: Instead of Use Cases, User Stories. Why? Well User Stories are written for/by the user. They are not an accurate description of functionality, but do specify what the user wants to do. This can be your initial road map into writing code that actually allows the user to do something, rather than comply with system ...


0

A test fundamentally tells you, "If I supply input X to program P, I get output Y." Test driven development works by writing X and Y first then filling in the gap. Work backwards. The program will produce some outputs. Whether these are control signals, images, web pages, text, lamps, toast, whatever: outputs. Produce some representative outputs by hand. ...


3

You cannot jump directly from "idea" to "implementation". Good example is the "V model" : You start at high level go lower and you write tests on each level. And each level gets more specific in both implementation and testing. For example you write an acceptance test that says that you should be able to add a customer. This results in you writing an ...


0

Writing use cases with (say a Product owner) could perhaps get you started. The problem for me is that "conception" in your graph and unit tests are on different conceptual levels. Unit tests are on a very low level (and are best viewed as a code design tool), they do not dictate or guarantee system level features. I would start by writing automated high ...


1

Given a scenario, when some method is called the data must be persisted into db and have following steps: Setup empty db simulator (you call it mock) and pass it in as a dependency do call the method you are testing Verify the data was stored in simulator OR Setup db simulator with predefined data and pass it in as a dependency do call the method ...


0

From the OOP point of view functions can be considered to be single-method interfaces. Interface is a stronger contract than a function. If you are using a functional approach and do a lot of DI then in comparison to using an OOP approach you will get more candidates for each dependency. void DoStuff(Func<DateTime> getDateTime) {}; //Anything that ...


3

In this case I would say DEFINITELY. You are taking an action in a property that is above and beyond a simple value set. Unit tests will not only validate your design they will declare this as intent to future developers that come along and think about removing your additional code.


3

In general, don't test trivial methods containing no logic. Once your getter or setter contains logic, then you can apply a unit test. Logic can be anything from an input validation to a full blown implementation of something.


5

is Functional Programming a viable alternative to dependency injection patterns? This strikes me as an odd question. Functional Programming approaches are largely tangential to dependency injection. Sure, having immutable state can push you to not "cheat" by having side effects or using the class state as an implicit contract between functions. It ...


8

Dependency management is a big problem in OOP for the following two reasons: The tight coupling of data and code. Ubiquitous use of side effects. Most OO programmers consider the tight coupling of data and code to be wholly beneficial, but it comes with a cost. Managing the flow of data through the layers is an unavoidable part of programming in any ...


0

If you do not own the REST API's, your responsibility ends with them You need tests that check if your application calls the API under your control correctly. Therefore, use the actual application with the actual service (the one you control) but calling mocked services (the ones you don't control). So... Use canned data for the services you don't ...


0

A good example for this comes from code I have seen recently: if foo bar == baz # should be bar = baz In python expressions like this work totally fine but they don't do what you intended. Another typo in the same code: class foo: ... def bar(self): ... def foo_bar: ... ... foo.bar() # They meant to use foo_bar() Sure ...


3

Unit tests don't actively prevent type errors, but they do provide you a mechanism to execute the code you have written before the entire application is complete. If you try to do something silly, like mistyping calculateInterest as claculateinterest, then that will be caught early on if you use a statically typed, compiled language like Java because the ...


0

Even though it is right that you should not start testing your tests the ability of a test to fail is crucial. A test which cannot fail is not only useless - it also indicates that you ... made logical mistakes just wanted to do some quick testing without thinking it through or are testing the language (e.g. unsigned >= 0) or general logic (true || false) ...


3

what is a good guideline to ensure that it is in fact testing the proper test case This falls back to the old "who tests the tests?" line of thinking. And in general, nobody can test the tests. Unit tests have proven themselves so successful in part because they are small enough that they can be implemented without error. A good guideline is that ...


2

In a summary you don't want to use tools/techniques for doing things other than what they are meant for. What you are trying to do sounds like a concern that could be solved easily with a CI (continuous integration) practice. This way you can keep your tests atomic as already suggested and let the CI take care of verifying your tests. If any tests fail ...


2

In my experience, unit tests take as long, or longer, to write than the code you're testing because you frequently have to test multiple conditions, especially when targeting 100% branch coverage. It often feels like you're developing a second application in parallel. Generally, it takes as much skill, or more, to develop good tests because you need to have ...


0

Writing good tests fast requires practice The time you need to write good (unit-) tests depends on your practice on writing them. At first it will probably slow down your progression but in the end you will most likely profit from doing so. But unit tests will save you a lot of time. It is almost never possible to compile and run every single line of code ...


0

Unit testing and TDD are similar but the differences are important. Unit tests make no demands on having been written first, before the production code. TDD does. This leads to different code designs. I argue that TDD produces better code. There's plenty of online explanations for justification. Unit testing requires skills and TDD requires even more ...


0

If you have a large application without unit tests and you want to add unit tests to all the existing code, then it can take a very long time. But that's probably not a good idea as you'll probably have found most of the easy bugs some other way already. TDD usually implies writing tests as part of the coding process, and as such it's hard to say how long ...


1

It depends. If you have a simple web app where you send in "Foo" and recieve "Bar" back then no, it's easy. Though you should not only create tests for the "happy path", you should also check that unexpected input doesn't cause havoc. Most web apps are not simple though. This ties in to question 2. Yes and no. You call a method, but that method may have ...


3

It depends on your tooling, but you probably can't (and shouldn't) Some Unit-testing frameworks (take PHPUnit for example) allow you to 'chain' tests so that a failing test on one level does not execute other tests. However, I doubt that this will fix your problem for this situation. Not allowing guaranteed test order execution forces tests to be isolated ...


3

There is no point to making sure that every defect in your system trips exactly one test. A test suite has one job: verifying that there are no known defects. If there is a defect, it doesn't matter if one test fails or 10. If you get used to your test suite failing, if you try to gauge how "bad" your program is by counting the failing tests, you're not ...


1

Making the methods public - yes, that is bad practice. Making them internal - that depends. Instead of making all methods to be tested public, and instead of redesigning your classes completely, sometimes the most pragmatic solution is to make the methods in stake "internal" and use the "InternalsVisibleTo" attribute to allow your unit tests access them. ...


2

You should not have to change your unit tests if you have only changed internal implementation details and not the API. The fact that your old tests still work after a change is the proof that your changes have not broken things. You can look at the commit log, see that absolutely nothing in the test code has changed and feel reassured (as long as your ...


12

Yes it is very bad practice - you're letting your tools make design decisions for you. I think the main problem here is that you're trying to treat each individual method as a unit. This is generally the cause of all unit test woes. Except for some cases where your method is very complex and requires a lot of testing, you should be treating your classes as ...


6

If you have methods 'assisting', chances are your single, big method is actually doing too much. Splitting into smaller methods and then moving these methods into separate classes with public interfaces keeps the class with the big method responsible for one thing and one thing only (see Single Responsibility Principle). This move into separte classes ...


1

The simple truth rarely acknowledged is that if a class contains a compiler-visible dependency on another class, it cannot be tested in isolation from that class. You can fake up something that looks like a test, and will appear on a report as if it was a test. But it will not have the key defining properties of a test; failing when things are wrong, ...



Top 50 recent answers are included