New answers tagged

0

Unit Tests and Integration Tests are orthgonal to each other. They offer a different view on the application you are building. Usually you want both. But the point in time differs, when you want which kind of tests. The most often you want Unit Tests. Unit tests focus on a small portion of the code being tested - what exactly is called a unit is left to ...


2

If you encapsulate all IO operations in a small class with an interface and inject it to the archiving class you can mock calls to the IO system during testing. public class Archiver { public IFileSystem Filesystem { private get; set; } public void DoWork() { //business logic here } public Archiver() { Filesystem = new ...


0

Certainly this is how I present test cases in an interview context (though I'm the interviewer in these cases). Doing this ahead of time would be a very positive thing. Identify the likely corner cases, bases cases, etc. and then move on to the design. You could ask the interviewer if they want you to talk more about testing the code before you proceed, ...


2

There are multiple ways of doing this. The one most closely resembling your production setup would be to use an in-memory database like H2 and plug that into your system while testing. Then you can just export the rows in question and start your test with importing a bunch of rows. H2 can be run in "MySQL mode" if you're running MySQL; that makes it mainly ...


0

Once you have a rough idea of what a class or function should do, you have enough information to write tests. These tests may fail, due to the thing you're testing being broken, but that is essentially a good thing. If you prefer writing the code before you write the tests for the code (sometimes, having an implementation may yield a better idea of what ...


4

You should be creating tests for all the code that you write, regardless of whether they're libraries or your application. Why ? you can assert that the code you write works the tests assert that that code continues to work as you change or add subsequent code. In short, it doesn't matter whether it's a library or an application that you're writing code ...


0

I'll post my last comment to fschmengler's answer as an answer since I think that it is the most fitting way to solve my question. I think that my problem was that I was facing the problem the wrong way: the handler shouldn't be validating any of that since it's bussiness logic; not even indirectly as it is doing it now. Both the handler and the validator ...


1

I agree with Erik Eidt's answer, but there is a third option: stub out the constant in the test, so the test passes even if you change the value of the constant in the production code. (see stubbing a constant in python unittest) foo = FooSaver("/tmp/special_name") foo.save_type_a() foo.save_type_b() with mock.patch.object(FooSaver, 'A_FILENAME', ...


2

In Ruby on Rails, which places validation logic in the model rather than in the controller or otherwise closer to the front end, the pattern used is to provide both a Boolean and an error dictionary. After an object has been validated, you can access the errors dictionary which has property names as keys, and a set of error description strings as the value. ...


4

It should be pointless. But you should be making sure handler calls what validator needs called. For unit testing you should be testing in isolation. That means you'll need a stub (or mock) validator to hand to handler when you test handler. You don't check validator business logic when testing handler. You test that handler calls validator (in this ...


2

Obviously I want to make sure that the validator is called when the handler does its thing Then mock the validator and test that it is called with the right parameters. No need to test the validator itself twice. On a related note, unit tests have their true value in test driven development. It sounds like you are writing the tests after the code ...


2

Instead of bool you could return some integer error code or even validation message in string. This would provide you a knowledge of what failed the validation. The string solution have also particular advantage because you already have composed message to inform end user about results of validation.


2

What @Erik suggested--in terms of making sure you are clear on what it is you are testing--should certainly be your first point of consideration. But should your decision lead you to the direction of factoring out the constants, that leaves the interesting part of your question (paraphrasing) "Why should I trade off duplicating constants for duplicating ...


4

You already captured the crux of your question: a non-Serializable object can be difficult to mock in the way you are describing. What you are looking to do is less of a unit test and more of a system test. You can implement this as a unit test (e.g. JUnit) but it will not be efficient. It sounds like you are essentially trying to unit test using real DAOs ...


13

I think it depends on what you're trying to test, which goes to what the contract of the class is. If the contract of the class is exactly that FooSaver generates a.foo_file and b.foo_file in a particular location, then you should test that directly, i.e. duplicate the constants in the tests. If, however, the contract of the class is that it generates ...


0

If it's easy to do it with queries, do it with queries. It sounds like the whole thing should be a stored procedure. As others have said, I don't think a unit testing framework will be much help to you here.


0

You seem to be labouring under a misapprehension about unit testing. Good unit tests adhere to FIRST principles: Whilst this may well be a valid test of your business rules, it clearly isn't a repeatable test since the source data can change over time. What you can do is write unit tests to create various data scenarios and check that your business rules ...


5

Been there, done that. First let's make something clear: That's not unit testing. Unit testing is about code. You are not runnning the tests after a code change to test if code alterations introduced a bug or unwanted behavior. Instead you want to run some routines at the end of a business day to see if some business performance indicator has met some ...


0

How to test send method (that I really send what I want)? I can't mock it. I can write that HTTPClient receives SomeLibrary::ClientSession object in constructor (in test I would pass mock) but is it good design? Yes. You should definitely inject the connection/session into the client. I think that the way of implementing of session etc. should by ...


0

You could use static inheritance, and inject the object through the template argument. Then in the unit tests, inject the mock object, instead of the real object. Something like this : struct A { void doThings() { } }; struct MockA { MOCK_METHOD0(doThings, void()); }; template< typename doer > struct B { void foo() { a.doThings(); } ...


1

You usually mark class as virtual when, besides having some sort of implementation (either directly in the class declaring the function itself or in a child inheriting this class), you want the declaration to state a contract, which must be fulfilled by the implementations. The declaration basically says: If you give me this set of parameters of these ...


1

Your design or test is wrong. Instead of mocking using a framework, try create your own derived class and design your test around this "mock" class. You will realize that idea of mocking non-virtual methods doesn't make any sense. The idea of virtual methods is that the base class wants some functionality and expects it's children to provide it. If the base ...


2

Yes, it would be a good design to break that direct dependency on the session implementation and instead inject it. (Not only for testing purpose.) template <typename SessionT> class HTTPClient { private: SessionT session_ {}; public: HTTPClient(SessionT session) : session_ {std::move(session)} { } // Optional convenience overload ...


1

There's always a trade-off between creation and testing, I could create a perfect product, just come back in 10 years and it'll be ready.. and no manager will ever accept that estimate (or the cost :) ) So you have to be pragmatic, unit tests do not catch all bugs, so you should not try to create unit testing environment that is 100% perfect with 100% code ...


0

"Hammer in a nail - if the wood splits you should have used a screw" How do you know if you're not writing enough tests? If bugs appear further upstream that could have been caught at the unit test phase then you haven't written enough tests. But this aside, I sense you're equally interested in the expended effort as heading off possible bugs. If you find ...


4

Every one of those outcomes that you described are valid testing scenarios. The way you know that is that each behavior is tied to a different outcome. That makes each one a prime candidate for testing. From a Cyclomatic Complexity point of view, the fact that there are different outcomes for each test corresponding to different program states almost ...


4

Unit tests test a code unit, which may be larger than a method. It is usually not possible to test setter–getter and constructor–getter pairs separately, and that is OK. You'll naturally have test cases like “contains inserted elements” and “doesn't contain elements that weren't inserted”. In such cases, I focus my tests on that method which modifies the ...


5

Your test cases, if done well, serve two purposes: They check that no existing functionality has broken when making changes to the code in the future; They document how the code is to be used and how it behaves. If you just had one check, TEST(BinarySearchTree, Insert) { BinarySearchTree t; t.insert(5); EXPECT_FALSE(t.contains(2)); ...


0

Have you considered using XML rather than JSON? XML has several robust and mature solution for validation, eg. XML Schemas. JSON is generally considered the simple and lightweight alternative to XML, but it is only simpler if you don't need the more advanced features of XML, like validation. With an XML schema you can validate the XML request and response ...


1

Nothing is fool-proof, and the general case of "how do I know I'm testing every relevant scenario?" is "you can't know that", but there are approaches that attempt to systematize the coverage of relevant test cases. With Equivalence Partitioning, you attempt to define an equivalence relation between groups of input data, and then only test one example of ...


3

Assuming you have a pure function, IE one that doesn't rely on any internal state carried over between calls, you would want to generate something like a truth table. As @KilianFoth notes in his answer this is generally impractical for anything interesting. Since as soon as you pass in something like an integer you have a huge possible input set, and with a ...


1

Usually, you can't. If the task you're programming is large enough that it's easier to write a computer program than to do it by hand, then the number of possible input/output pairs is probably too big to be tested exhaustively. But writing a test case against every instance of a previously encountered error goes a long way towards code that handles all ...



Top 50 recent answers are included