Tag Info

New answers tagged

0

there seems to be a debate online about whether private methods should be tested or not. Really? Where is this supposed debate? If it's part of your software, it needs to work. Usually, that means testing it to make sure it works. If I have an interface that exposes one method, but that method is quite complex and calls multiple other private ...


2

No, it's not an integration test. A unit test tests one unit of executable code, and in procedural languages that usually equates to a method. The test must make sure that this unit of code does its own task correctly, and nothing else. If our method calls multiple private methods, then you must test the effect of all those private bits of code. For ...


1

First off, there seem to be many approaches to testing code automatically. The term "unit testing" seems to have been bastardized to mean any automated testing. In its pure form, a unit test tests only one method. A test for a method that calls other methods or library functions is often called a functional test. Integration testing usually spans multiple ...


2

No, you do not need to add messages to most assertions. Writing unit tests as you suggest would be needlessly tedious. Presumably the Assert.IsTrue method will throw an exception saying something like "Expected true, got false". The ensuing stack trace will pinpoint the cause of the failure. N.B. In general, as a programmer, you should not be spending ...


6

It's not generally needed. As @Telastyn says, if the test case fails, then it will become quickly and readily apparent what method failed. The real need is to have the purpose of your test easily understood by those that are adding, reviewing, or modifying tests after you (even if that person is also you), and are reviewing the code and searching for ...


0

Its okay to write the interface/code/test at the same time as long as their incorporation into the project is atomic. Unless your boss is religious about TDD, in which case you probably have to write empty interface -> test -> minimal code (pointless step) -> more tests -> more pointless code -> more tests -> finally write the real code -> done.


2

In TDD should I have to write Test first or Interface first? It all depends on how orthodox / religious you want to do TDD. I am learning TDD Since you are learning, you should experiment to get a personal workflow, which works for you. If you want to do it according to the books, you write at first a test, which obviously will fail, because ...


9

Your first violation ("The code that is written for interface is not driven by test.") is not valid. Let's use a trivial example. Suppose you're writing a calculator class, and you're writing an addition operation. What test might you write? public class CalculatorTest { @Test public void testAddTwoIntegers() { Calculator calc = new ...


0

How do you test your code should not influence any design decision. It's better to ask yourself the question - would I ever provide at least two different implementations for the service? If the answer is yes, then define an interface for it. Usually you provide an interface, when you want to easily interchange two or more implementations (like PnP).


7

Yes, you should unit test all of the branches of your function, especially one like this where it is easy to do so. (though I might also recommend refactoring this code, as it violates the spirit, if not the letter of the Law of Demeter)


1

Testing code is still code, intended to accomplish some function. That it's a "back room" or "back stage" function is just a detail. Now, you have a codebase with 200 functions, that minimally accomplishes the coverage you need, and only 10% works. If this were a user-facing codebase, you'd probably conclude it wasn't worth updating as-is, where-is. That a ...


1

This kind of testing is why mocks were invented. The main idea: You write a mock for your object (map, behavior, character, ...), then write tests using that mock instead of the actual object. People sometimes call mocks stubs, and I believe there are other words for both. In your case, you would write a mock for the map whenever you need to test the ...


-1

Language agnostic test framework are generic test framework suited for acceptance test (point of view) and testcases in that framework is managed by QA e.g Robotframework


4

Here are a few suggestions to at least get you started. Everything listed here is free. a webtest framework, which "clicks" through the browser/webapp - Selenium an extjs/javascript unittest framework - Jasmine or Mocha a C# unittest framework - NUnit perhaps a framework which tests whether web calls give correct return values, and how web calls react to ...


1

This is all general, not specific to your needs. Random stuff I learned from the process of adding unit tests to my C++ project (not all from personal experience): integration tests are not like unit tests. There are a lot of harnesses that only support unit tests, not integration tests. The same script that calls your test harness should also run a code ...


0

If this is all done just to make it possible to test the Extra class, then the code is overcomplicating matters. The code is asking for permission rather than for forgiveness. You are quite correct, changing the code to catch the ImportError exception would vastly simplify the codebase. The code shouldn't even try to test the detection, but simply rely on ...


0

I recently did this. Forgot where I read about it but it's pretty easy. Here's the basics of my code. var express = require('express'); var http = require('http'); var MyServer = function(options) { var app = express(); app.get(/^\/foo.html/, sendFoo); app.get(/^\/bar.html/, sendBar); var server = options.server || http.createServer(app); ...


2

The only choice that is clearly wrong is "Don't test the methods as they are very simple." Not testing is bad testing, regardless of how simple the methods are. Some developers favor very spare unit tests, in which "only one thing can fail." As a result, even simple methods might deserve many individual test functions/methods. To reduce boilerplate, ...


-2

I don't really see this as a Question and Answer problem but an entirely subjective one. The 'correct' answer is the one that gets the most complete and accurate set of tests. Boredom is the most defining obstacle with your 'problem': At one end of the spectrum errors will creep in because you're so bored by the repetition that your eyes glaze over and ...


0

You can write your code with lots of workarounds to stop you having to use friends. You can write classes and never have any private methods at all. All you need to then do is make implementation functions within the compilation unit, let your class call them and pass in any data members they need to access. And yes it will mean you can change the ...


1

Here's a questionable suggestion for a questionable question. I don't like the coupling of friend as then released code has to know about the test. Nir's answer is one way to alleviate that, but I still don't much like changing the class to conform to the test. Since I don't rely on inheritance often, I sometimes just make the otherwise private methods ...


7

If it's hard to test, it's badly written If you have a class with private methods complex enough to warrant their own test, the class is doing too much. Inside there is another class trying to get out. Extract the private methods that you want to test into a new class (or classes) and make them public. Test the new classes. In addition to making the ...


4

Hardware-dependend test can be hard to unit-test, indeed, until you have a reliable simulator available. OS / kernel dependent code can be unit tested by providing an abstract interface to the OS or kernel functions which allows to mock these functions out Of course, when your OS functions do not behave the way you expect them to behave, you might provide ...


2

There are a few options to do this, but keep in mind that they (in essence) modify the public interface of your modules, to give you access to internal implementation details (effectively transforming unit testing into tightly coupled client dependencies, where you should have no dependencies at all). you could add a friend (class or function) declaration ...


8

An alternative to friend (well, in a sense) that I use frequently is a pattern that I've come to know as access_by. It's pretty simple: class A { void priv_method(){}; public: template <class T> struct access_by; template <class T> friend struct access_by; } Now, suppose class B is involved in testing A. You can write this: template ...


6

You shouldn't be testing private methods. Period. The classes using your class only care about the methods that it provides, not the ones it uses under the hood to work. If you're worrying about your code coverage, you need to find configurations that allow you to test that private method from one of the public method calls. If you can't do that, what's ...


4

I think you are going about this the wrong way. Don't get into an argument over the definitions of words, that's not useful. Trying to argue for changes in development methodology by arguing over the definition of an integration tests, is like try to square a circle by changing the definition of a square. Instead, argue for what you actually want to change. ...


0

I am guessing that there will be plenty of other factors that are coming into play that you might not have considered. They are probably not technical. Eg, time, effort, understandability, simplicity, upcoming future work, previous decisions already made, etc. There is obviously a lot of conflict around the database. You need to take a step back here, he's ...


1

Challenging someone who thinks they know best is always a problem. You have run into someone who believes "everything is a unit test," and that kind of miscategorization is hard to address. Provide him with a scale of interactions, that has some hierarchy to it. Ask him to draw lines where he wants to define things. For instance. Single method/procedure, ...


4

I think that when you are dealing with people who think they know best, or you are just in a position where they don't think they should be listening to you, the best way is question their ways. He is probably the type that believes that he should be the one making the decisions (independently of whether or not he is the most qualified). And just telling ...


2

If a method is too large to effectively unit test- meaning it is most likely doing too many things for one method- then there are two approaches you can take: Split the method into several methods to be called sequentially Abstract parts of its functionality behind other methods In your question you seem to focus on 1, but most of the time, 2 will be the ...


4

In my opinion Actions should be relatively small and delegate work to other objects. Actions should (again, in my opinion) simply be responsible for the following: Receiving the request Delegate work to other objects Return the result in the correct format If you do this then unit testing becomes much easier through the use of mock objects and Dependency ...



Top 50 recent answers are included