New answers tagged

1

I have always followed the maxim that a unit test tests one thing and only one thing. Programming such that each method does one thing and one thing only, should mean you can write a unit test for that method fairly easily. If your method calls out to any other services or classes, then you should mock those so their behavior during the test is completely ...


0

In all cases of Unit Testing, you have to define what a unit is. Its impractical to make it too small, and unhelpful to make it too big. Martin Fowler says to make it a class, sometimes (importantly): "I often take a bunch of closely related classes and treat them as a single unit" I assume he means that a unit for him is a class, but sometimes, if ...


0

The thing with any form of testing is that in order for it to be worthwhile, when it finds defects, you have to fix them. While it is very easy to instead change your tests to match the buggy behavior, this invalidates the whole exercise. In this case, your testing has found defects: your internal functions have paths that are not reachable from tests of ...


2

Have you considered putting the functions into the module's header file, but putting them in a conditionally compiled block that is only enabled in build configurations that are tested? It would be analogous to having a C++ class with public and private functions. However, that's not a good option if you're shipping the header file to users, and want to ...


3

Adding unit testing to a project in retrospective is usually more pain than it is worth. There is a reason why the red/green/refactor workflow mandates to write the tests first and the code which passes them afterwards. In order to be properly testable, the whole code architecture must be designed with unit-testing in mind. You need to follow patterns like ...


3

TDD isn't about debugging, it is about proving the code functions as expected. Strictly speaking, the tests should have been written before the code but you are where you are. Unit tests benefit future developers since failing tests should raise a red flag that they've inadvertently broken something and should attend to it. That isn't to say there is no ...


3

You will normally keep your tests in a separate folder hierarchy as they usually aren't part of the binary you ship, and it's just simpler to not mix them up, but you keep them in the same repo and branch because they belong together in source. As for where you work, TDD means Test Driven Development, which means you first write a (small) test for the ...


6

The basic workflow for TDD is commonly known as "Red; Green; Refactor": Red: Write a failing test Green: Modify the code to make that test pass (without any existing tests failing) Refactor: Tidy up the code to better incorporate the change. There are numerous resources that explain this process in details, eg The Cycles of TDD It's unclear to me as to ...


2

The tests aren't there to ensure you write the code you want to write. They are there to ensure that three years from now, you don't accidentally change the way the code works through a seemingly unrelated change, causing unintelligible defects. Tests are insurance against the future. Never remove the tests.


2

Unit tests are supposed to be for external functions only. Nevertheless, if you have a lot of "internal code", it should be tested too right? So how? Make smaller functions, separated from you code (another .c and .h), and use those functions as a library that can be unit tested. Then you should be able to test those functions that are used by the internal ...


1

Testing terminology is very messy. Usually I've seen this type of tests to be called "integration tests", but to me it seems to be too overloaded term used also for quite different type of tests. So I call them component tests. Your microservice is one component of the larger system. Term is quite self-explanatory and fits well definition from Martin ...


0

I would call it just "unit tests". And Mock objects are very common in Unit Tests, because those need to be independent from each other ( so test of feature X cannot depend on test of DB connector ).


3

I wouldn't say reasons exactly but they do provide a good sense check. All tests being the same (not attributed), you'd expect this to be 100% for a full run. Anything less than this suggests you have dead code which could be removed. For CI builds, it is quite common to ignore integration tests so it is useful (for me as a build manager) to see this as I ...


5

To validate an XML file, you first need an XML Schema Definition (XSD) that describes the structure of a valid XML document. You can find the specification for XSD files at W3C. Going into how to build the XSD requires knowing how your XML should be structured. For detailed information about the actual Java implementation of this, check out What's the best ...


2

Working on a C# Server with SQL Server and PetaPoco, this is the approach we took to clean-up data in Unit Tests. A typical unit test would have Setup and Teardown as follows: [TestFixture] internal class PlatformDataObjectTests { private IDatabaseConfiguration _dbConfig; private Database _pocoDatabase; private PlatformDataObject _platformDto; ...


3

For me there is a simple criteria to decide if automatic tests are needed: Are you planning to evolve and maintain the project? "Yes" - you should write tests. There are some cases when you can go without tests, mostly it is "do once and forget" type of work, like small web-site, CMS setup, etc. Everything which you do quickly, test if it works and forget ...


2

Let's ask an equivalent question: Why would you build the code on a CI server? Surely, by the time something gets committed to master, a developer has already built the code before and fixed any errors that might've occurred with their new code. Isn't that the point of building code? Otherwise they've just committed broken code. The are ...


0

"All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident." - Schopenhauer At a macro level the argument was had a long time ago with formal testing. The argument was that programmers are highly trained professionals who should write code without defects. This is of course ...


0

Not a strict unit test, but a runtime check that has helped me with some intermittently failing tests. It's quick & dirty, but it worked. When a mutex is granted I keep a track of which thread has it. All mutex requests have a thirty-second timeout, after which they scream deadlock. I can then use the list of granted mutexes to see which thread is ...


4

Besides the fact that this is an integration test as opposed to a unit test, the operations you describe typically go in Setup and/or Teardown methods. Frameworks like nUnit allow one to decorate class methods with these attributes to indicate whether the method is a setup method or teardown method. Then your tests should become cleaner and smaller as the ...


4

The big problem with databases and (unit-)tests is that databases are so darn good at persisting stuff. The usual solution is to not use an actual database in your unit-tests, but instead mock the database or use an in-memory database that can easily be wiped completely in-between tests. Only when testing the code that directly interacts with the database, ...


7

The point that you should be aiming for with such tests is that as many of them as possible should be interacting with a mock of the database, rather than the database itself. The standard way to achieve this is to inject a DB access layer into the logic you are testing here, using interfaces. That way, the test code can create in-memory data sets prior to ...


3

It is possible to imagine cases when the change A does not break the test, and change B does not break the test, but A and B together do. If A and B are made by different developers, only CI server will detect the new bug. A and B may even be two parts of the same longer sentence. Imagine a train driven by the two locomotives A and B. Maybe one is more than ...


2

One of the primary strengths of DI is that you can inject completely different versions of the dependent services based on your environment. More specifically, in your unit test environment, you can inject a DomainMapper implementation that just returns canned data and does not access the database in any way. You can even vary the DomainMapper instance for ...


2

I think you listed the differences very well in your answer, however I'll add my some of my opinions on how I view the two approaches. AAA is very useful for me when I'm testing my own code. If I'm working on a project or a library for myself, AAA is the way that I go. It lets me set up whatever I need to execute my test and then just test it. It's ...


22

Apart from the excellent Oded answer: You test the code from the repository. It may work on your machine with your files... that you forgot to commit. It may depend on a new table that does not have the creation script (In liquibase for example), some configuration data or properties files. You avoid code integration problems. One developer downloads the ...


68

As a developer who doesn't run all the integration and unit tests before making a commit to source control, I'll offer up my defense here. I would have to build, test and verify that an application runs correctly on: Microsoft Windows XP and Vista with Visual Studio 2008 compiler. Microsoft Windows 7 with Visual Studio 2010 compiler. Oh, and the MSI ...


3

Assuming (contrary to other answers) that developers are quite disciplined and do run unit tests before committing, there can be several reasons : running unit tests can take long for some special set up. For example, running unit tests with memory checker (like valgrind) can take much longer. Although all unit tests are passing, memory check can fail. the ...


14

by the time something gets committed to master I usually set up my CI to run on every single commit. Branches don't get merged into master until the branch has been tested. If you're relying on running tests on master, then that opens a window for the build to be broken. Running the tests on a CI machine is about reproducible results. Because the CI ...


2

I guess it's dependent upon the framework you're using. Generally, so far as my understanding, AAA is supported by the NUnit framework, and thus is the natural choice in that regard. As for the theoretical differences between TDD and BDD, they appear to be slight. See this link, someone more qualified than myself to give you an explanation.


4

By the time something gets committed to master, a developer should have already run all the unit tests ... but what if they haven't? If you don't run the unit tests on the CI server, you'll not know until someone else pulls the changes to their machine and discovers the tests just broke on them. In addition, the developer may have made a mistake and ...


187

Surely, by the time something gets committed to master, a developer has already run all the unit tests before and fixed any errors that might've occurred with their new code. Or not. There can be many reasons why this can happen: The developer doesn't have the discipline to do that They have forgotten They didn't commit everything and pushed an ...


22

You'd think so wouldn't you - but developers are human and they sometimes forget. Also, developers often fail to pull the latest code. Their latest tests might run fine then at the point of check-in, someone else commits a breaking change. Your tests may also rely on a local (unchecked-in) resource. Something that your local unit tests wouldn't pick up. ...


0

TLDR There are two options: Continue testing as a whole with functional tests (because these as a whole tests are not unit tests). You can feel this is not the right way, but it can be the only way to go with your current code base. Refactor code to smaller units (classes / functions) to make real unit testing possible. Then create unit tests for these ...


0

A unit test should be able to use any code or logic that itself is properly tested. A unit test should have minimal logic in it. It should be straight forward as to its test and that one can look at it and reason about it. Reimplementing an equals method violates DRY. In doing so, it introduces the possibility of having equals diverge and a bug slip in to ...


0

Usually you can't write a test for a method before at least the declaration of the method has been written, because the test won't compile. And you can't run the test before at least an empty definition for the method is written, because the test won't link. So the best order is: (a) Plan what you want to do. (b) Write the declaration for the method. (c) ...


1

At what point in that process should I really begin testing? Well, you asked specifically about tdd, so there's really only one correct answer: Before you do anything else. Test-Driven Development and Design is called Test-Driven, because the Tests drive the development and design. The tests tell you when to start writing code. They tell you what to ...


5

TDD revolves mostly around unit testing, this answer is going to cover that. Why do you make applications? Do you make them to see see that C# works well, or do you make them to solve a problem presented by your client (be aware, sometimes the client may as well be you)? Unless you are a .NET developer working for the Microsoft company and are actually ...


6

Your deserialization test should take a String as its input, and try to produce a present-day object from it. Therefore, all you have to do is revert a copy of your project to an earlier state, save a serialized String, return to the head, and put that string into your test data. Unless I misunderstand your question, you never need to have different versions ...


-1

How I see TDD done with implementing tests for an unfinished code is, write tests first with [ExpectedException] attribute or similar. This should pass initially as the incomplete code would not have any logic in it and write a throw new Exception() code in it. Though throughing exception is wrong, this would atleast make the tests pass initially and fit for ...


0

I can see 2 possibilities : The author is referring to private method names being included in the stack trace when a unit test fails unexpectedly. Hence as we already mentioned, newly written unit tests allow you to more easily identify the root cause of your failing tests. What still puzzles me is newly written unit tests. What does he mean, and ...


5

No one said unit tests have to be run all on the same platform - but no one said you could reach 100% test coverage either. As a first step, #ifdef out the code, preferably factoring it into a platform-specific function. Write a suitable implementation of this function for x86. However, I don't think it is appropriate to select the code to be compiled based ...


4

After having written lots of test, I am strongly in favour of splitting up large methods, and of testing private methods. Splitting up functionality into smaller steps has two great advantages: By introducing a name for an operation, the code becomes more self-documenting. By using smaller methods, the code is simpler and thus more likely correct. E.g. you ...


2

Quis custodiet ipsos custodes? Your test framework had bugs in it, which means that your tests were buggy. This is the problem with complex tests and complex testing systems. One way to deal with this is to create unit tests for the complex parts, and then confirm that they behave correctly. In other words, it's just software, and if it isn't dead ...


1

You will need to run all tests eventually as you're making a fundamental change. However you don't have to run all tests at once. Rather then fixing the bug, you could deprecate the bug causing functionality, create a new and correct bit of functionality which over time replaces the old functionality.


4

When you change the behaviour of a component in your framework, then just unit-testing that component is not sufficient. You must also re-run the integration- and higher-level tests that involve that component to verify what effect your changes have on the rest of the system. If you find that the effect of your change is very large, the either you should ...


0

It would be perfectly logical to write a separate unit test for match, because it's quite non-trivial. The code you showed for match is a pretty trivial 1-liner without any tricky edge cases, or is that like a simplified example? Anyway, I'll assume it's simplified... Question: what's the point of putting functions and constants into the ...


0

Try working at a higher level -- what use case that the business cares about will fail if TTL isn't 30 seconds? More generally: Don't write unit tests for things that can't fail; it annoys the pig. Writing tests that verify a specific implementation is usually a bad idea. When you later come up with a better way to implement what you need, all of those ...


2

The unit tests need access to this constant, in order to verify that cache entries aren't removed before their time to live has expired. The actual value given is irrelevant, I'd think. Therefore: make this constant public and document it. After all, the time to live is not a secret but results in externally observable consequences. If you like, you can ...


1

If you want to unit-test the private implementation-details, you do the same sort of dodge for unnamed namespaces as for private (or protected) class-members: Break in and party. While for classes you abuse friend, for unnamed namespaces you abuse the #include-mechanism, which doesn't even force you to change the code. Now that your test-code (or better ...



Top 50 recent answers are included