Tag Info

New answers tagged

0

Provided good TDD applied, test data tends to grow faster that actual code. Try splitting the test data into smaller pieces and reusing common ones. Yes, historically We are moving to dbsetup


1

Behat is at its best when used a Behaviour Driven Development tool. Try to think of your feature files as requirements, not tests. Change the requirements first, then alter your system to get the tests passing! To answer specifically your question about languages, if you do have a multi-language site, try putting an extra step like 'Given I'm an Englishman' ...


0

Writing unit tests is part of the design process, whether you do TDD or not. So of course it's something to be done by the developer. Integration tests, now these can be written by someone else. Unit tests, however, are closely related to implementation and they affect the architecture. Because even if we don't use TDD approach in strict sense, we ...


1

Directly testing your own code is good form, and a system that encourages someone other than the developer to test it is a hazard, as the code may not even be testable without heavy modifications. That said, expanding a project's unit test suite is a great way to get yourself on board with now it works. TDD style test first coding works very well in a ...


3

@CarlManaster has the right idea: It's the responsibility of the developer to: write a unit test, verify that it fails, implement it, verify that it succeeds, refactor the feature without failing the test, and finally refactor the test code for every feature. The reason for each of these can be summarised as follows: Writing the test before the code ...


0

With jUnit4 you can use the @Ignore annotation for the tests you want to postpone. Add the Annotation to each method you want to postpone, and continue writing tests for the required functionality. Circle back to refactor the older test cases later.


4

To me, though, it seems like overkill to pass in the time as an argument. You're right, and with mocking you can make the code testable and avoid passing the time (pun intention undefined). Example code: def time_of_day(): return datetime.datetime.utcnow().strftime('%H:%M:%S') Now let's say you want to test what happens during a leap second. As ...


1

Remember many rules in programming are essentially recommendations you can follow. So sometimes this is acceptable. Unit tests are called that way because they focus on testing single units of work. Generally, if you need more than one assertion per test case, you are structuring your test inappropriately. testing alternative code flows in the method, ...


1

A unit test should test the job that the tested unit has, no more, no less. If your method has the job of acessing the database and issuing UPDATE and INSERT commands as required, then that is what you have to test. When your collaborator is a data base, then issuing SQL is not an implementation detail: it is the behaviour of that unit. Compared to the ...


4

From my experience, one of the most important and most far-reaching decisions you make when building a program is how you break the code down into units (where "units" is used in its broadest sense). If you are using a class-based OO language, you need to break all the internal mechanisms used to implement the program into some number of classes. Then you ...


8

Writing testable code is important if you want to be able to prove that your code actually works. I tend to agree with the negative sentiments about warping your code into heinous contortions just to fit it to a particular test framework. On the other hand, everybody here has, at some point or other, had to deal with that 1,000 line long magic function ...


0

When you write a test, how do you know it will detect a fail condition? The answer is "test the test". How you do that is to write the test first, see it fail, and only see it pass when the unit under test has been coded successfully (the red/green/refactor cycle mentioned in one of the other answers). Writing the code first and then the test leaves open ...


1

If you are going with SOLID principles you will be on the good side, especially if extend this with KISS, DRY, and YAGNI. One missing point for me is the point of the complexity of a method. Is it a simple getter/setter method? Then just writing tests to satisfy your testing framework would be a waste of time. If it's a more complex method where you ...


8

It certainly has a cost, but some developers are so accustomed to paying it that they've forgotten the cost is there. For your example, you now have two units instead of one, you've required the calling code to initialize and manage an additional dependency, and while GetTimeOfDay is more testable, you are right back in the same boat testing your new ...


11

At some point the value needs to be initialized, and why not closest to consumption? Because you may need to reuse that code, with a different value than the one generated internally. The ability to insert the value you are going to use as a parameter, ensures that you can generate those values based on any time you like, not just "now" (with "now" ...


4

A quality of well-written code is that it is robust to change. That is, when a requirements change comes along, the change in the code should be proportional. This is an ideal (and not always achieved), but writing testable code helps get us closer to this goal. Why does it help get us closer? In production, our code operates within the production ...


8

It's possible that not every characteristic which contributes to testability is desirable outside the context of testability - I have trouble coming up with a non-test-related justification for the time parameter you cite, for instance - but broadly speaking the characteristics which contribute to testability also contribute to good code regardless of ...


9

It may seem silly to say it this way, but if you want to be able to test your code, then yes, writing testable code is better. You ask: At some point the value needs to be initialized, and why not closest to consumption? Precisely because, in the example you are referring to, it makes that code untestable. Unless you only run a subset of your tests ...


63

Is writing testable code still good practice even in the absence of tests? First things first, an absence of tests is a way bigger issue than your code being testable or not. Not having unit tests means you're not done with your code/feature. That out of the way, I wouldn't say that it's important to write testable code - it's important to write ...


103

In regard to the common definition of unit tests, I'd say no. I've seen simple code made convoluted because of the need to twist it to suit the testing framework (eg. interfaces and IoC everywhere making things difficult to follow through layers of interface calls and data that should be obvious passed in by magic). Given the choice between code that is easy ...


41

Yes, it is good practice. The reason is that testability is not for the sake of tests. It is for the sake of clarity and understandability that it brings with it. Nobody cares about the tests themselves. It is a sad fact of life that we need large regression test suites because we're not brilliant enough to write perfect code without constantly checking our ...



Top 50 recent answers are included