Hot answers tagged

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


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


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


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


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


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


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


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


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


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

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


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

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


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


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


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


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



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