Search Results

Search found 3 results on 1 pages for 'lhumongous'.

Page 1/1 | 1 

• Unit testing with serialization mock objects in C++

  - by lhumongous

  Greetings, I'm fairly new to TDD and ran across a unit test that I'm not entirely sure how to address. Basically, I'm testing a couple of legacy class methods which read/write a binary stream to a file. The class functions take a serializable object as a parameter, which handles the actual reading/writing to the file. For testing this, I was thinking that I would need a serialization mock object that I would pass to this function. My initial thought was to have the mock object hold onto a (char*) which would dynamically allocate memory and memcpy the data. However, it seems like the mock object might be doing too much work, and might be beyond the scope of this particular test. Is my initial approach correct, or can anyone think of another way of correctly testing this? Thanks!

  Read the article

• C++ and Dependency Injection in unit testing

  - by lhumongous

  Suppose I have a C++ class like so: class A { public: A() { } void SetNewB( const B& _b ) { m_B = _b; } private: B m_B; } In order to unit test something like this, I would have to break A's dependency on B. Since class A holds onto an actual object and not a pointer, I would have to refactor this code to take a pointer. Additionally, I would need to create a parent interface class for B so I can pass in my own fake of B when I test SetNewB. In this case, doesn't unit testing with dependency injection further complicate the existing code? If I make B a pointer, I'm now introducing heap allocation, and some piece of code is now responsible for cleaning it up (unless I use ref counted pointers). Additionally, if B is a rather trivial class with only a couple of member variables and functions, why introduce a whole new interface for it instead of just testing with an instance of B? I suppose you could make the argument that it would be easier to refactor A by using an interface. But are there some cases where two classes might need to be tightly coupled?

  Read the article

• What is the role of asserts in C++ programs that have unit tests?

  - by lhumongous

  Greetings, I've been adding unit tests to some legacy C++ code, and I've run into many scenarios where an assert inside a function will get tripped during a unit test run. A common idiom that I've run across is functions that take pointer arguments and immediately assert if the argument is NULL. I could easily get around this by disabling asserts when I'm unit testing. But I'm starting to wonder if unit tests are supposed to alleviate the need for runtime asserts. Is this a correct assessment? Are unit tests supposed to replace runtime asserts by happening sooner in the pipeline (ie: the error is caught in a failing test instead of when the program is running). On the other hand, I don't like adding soft fails to code (eg: if(param == NULL) return false;). A runtime assert at least makes it easier to debug a problem in case a unit test missed a bug. Thanks!

  Read the article

1