How to Write Clean, Testable Code

What people said

Recommends tucuxi · 2011-02 · Stack Overflow · on “Unit testing programs that mostly interact with external resources”

I recommend this google tech-talk on unit testing [this video] . The video boils down to write your code so that it knows as little about how it will be used as possible. The less assumptions your code makes, the easier it is to test. Avoid complex logic in constructors, the use of singletons, static class members, and so on. isolate your code from the external world (comms, databases, real time), and make sure that your code only talks to your isolation layer. Otherwise, writing tests will be a nightmare in terms of 'fake environment' setup. unit tests should test stories ; that is what we really understand and care for; given a class with a method foo() , testFoo() is uninformative. They actual

Recommends blunders · 2011-03 · Software Engineering Stack Exchange · on “What are the best resources for learning TDD?”

In my opinion, TDD is more about making the code testable, than writing tests. Sure you can write a test before coding, but the whole reason the test is written is so you can code -- which won't stop you from writing code that's hard to test. Take a look at this to get a better sense of what I mean: My Unified Theory of Bugs [LINK] If you're interested in the concept, and want to learn more, just comment -- and I'll point you in the direction of a recorded presentation on the topic from Google. UPDATE: How to Write Clean, Testable Code [this video] Miško Hevery [LINK] Presenting (By GoogleTechTalks [LINK] ) At Google in NYC [LINK] and sponsored by Google's Engineering Productivity [LINK] group

Recommends jbleduigou · 2011-09 · Stack Overflow · on “Not able to write the testcases for inner class using EasyMock”

First of all you need to think about what is the class responsibility. At should it be doing with who should it be speaking? Once you've clearly identified the dependencies you need to see how you can handle them in your code. You might need do to perform some refactoring in order to conform to the dependency inversion principle. For example here you have a dependency to the MailSender class but you won't be able to mock it as this dependency is "hard coded". There is a good video about that: [this video]

Recommends unholysampler · 2011-11 · Software Engineering Stack Exchange · on “Steps towards TDD”

One of the biggest ways to make your code testable is to use Dependency Injection [LINK] . This allows you to have a default implementation of the programming logic, but then when you go to test, you can mock that implementation in order to facilitate the tests. public interface Model { //methods } public class DefaultModel : Model { //default implementation } public class Worker { private Model _model; public Worker(Model model) { _model = model; } public void DoSomething() { var result = _model.Action(); //... } } //real code Worker worker = new Worker(new DefaultModel()); //test code public class TestModel : Model { //code for testing } Worker worker = new Worker(new TestModel()); //do te

Recommends Wojtek B. · 2012-07 · Stack Overflow · on “unit test best practice for method with mocks in Mockito”

First of all try to show somebody the test you wrote . It is hard to read in my opinion. You can't really tell from it what behaviour you are testing . A brief intro for you how to make it a bit more readable can be found here How to Write Clean, Testable Code [this video] . Using argument captors is also a smell. Some examples how to avoid it can be found on this tdd blog [LINK] . To answer you question , verify is used to verify interactions between classes. It is used to drive the design of your code. The result (if needed) should be specified by a when or given at the beginning of your test. Further information how to drive your design with mocks ( when , given , verify , ...) and how mocks a

Recommends Wojtek B. · 2012-07 · Stack Overflow · on “Designing a test for socket creation, TDD Java”

First of all testing abstract classes is not a good idea. You should test the concrete implementations. The abstract class is just a way of removing the code duplication (via IS-A relationship), you can remove duplication in many other ways (for example one I prefer is HAS-A relationship). Looking at your code and your question a good starter for you might be this video: How to Write Clean, Testable Code [this video] . It will tell you why the approach you took might not be a good idea and will point you to some sample solutions. Generally: specify scenarios/functionalities you class delivers. Don't test for implementation details. Good source of knowledge for beginners as well is this: Test Driv

Recommends jbleduigou · 2012-09 · Stack Overflow · on “Suggestion to mock out a private method which is generating random values”

The biggest flaw I can see in your code is the use of static methods. It really hardens the testing task (see this video [this video] ). Can you update UUIDGenerator class somehow? Maybe you could create an adapter class with an instance method calling this UUIDGenerator?

Recommends MariuszS · 2014-01 · Stack Overflow · on “Mockito test DAO with mocked objects”

Your code is not test friendly, especially this two lines are very bad for testing: EntityDao entityDao = new EntityDao(); UserDao userDao = new UserDao(); This code should be moved from this method to Factory or injected with containter like Spring (Dependency Injection). Mockito alone can't test code like this. Your method should do one thing only, creating Daos is other job. I will recommend you two films from GoogleTechTalks [LINK] : How to Write Clean, Testable Code [this video] The Clean Code Talks - Don't Look For Things! [LINK]

Recommends Andy · 2015-12 · Software Engineering Stack Exchange · on “Abstract classes with static methods in PHP”

Performance is not even the biggest problem here, secret dependencies and lying APIs are. From a testable point of view, static methods are awful, because they usually represent global state, which, surprisingly, is awful as well, because it means if you run a function two times, you can get different results even when the inputs are the same (that is what global state does). How do you test that? I cannot really see any case, where I would prefer static methods instead of normal ones. If you can, do not use them, if you must use them, your design is most likely wrong and needs refactoring. Check Clean Code Talks by Miško Hevery from 2008, they are still relevant and provide great explanatio

Recommends Erik Nyström · 2016-01 · Stack Overflow · on “Unit testing a fire and forget method”

Enter Dependency Injection [LINK] . Hide the analytics calls behind an interface. Create one implementation used in the actual production code, and one used only in the test. The test class could perhaps count the number of calls it has received and so on. Then you can verify it from the test by calling something like assertTrue(analyticsConnector.connectionsMade() == n); in your test code. A lecture/talk on the matter of testing and dependency injection [this video] . I recommend this video, there are some nuggets in there.