Hot answers tagged

189

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


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


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


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


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


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


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


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


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


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


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


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


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


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


4

You are testing two things, so you would be better off with two tests: [TestMethod] public void TestingClass_CorrectlyInitialisesProperty() { Testing tester = new Testing(); Assert.AreEqual(44, MyUnderlyingObject.Property); } [TestMethod] public void TestingClass_CorrectlyChangesPropertyViaSetter() { Testing tester = new ...


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


3

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


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


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


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


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


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

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

In general, something like this is a good idea. I'm not very experienced with JavaScript in particular, but have loads of experience testing other languages. And there I have found that exposing callback hooks like this is an extremely valuable technique to allow dependency injection without drastically changing the overall architecture – in fact, I recently ...


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


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


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.


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



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