Tag Info

Hot answers tagged

92

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


58

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


36

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


16

Sometimes test code contains snippets of code from third parties, both external and internal to your company. This happens as users file bugs; your tests (such as regression tests) then incorporate the code supplied by them to reproduce. Often, the licensing of such code snippets to reproduce bugs is unclear. So, you should be aware of intellectual ...


10

Shipping tests? Yes. Shipping Unit tests? No. As you say in the comment, problem you may face when running the product on a client computer will include problems such as linking with the wrong dll, generally this is not something a unit test will catch (which will no doubt have mocked the dll out to test the code). Now, shipping an integration test suite, ...


9

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


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


7

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


6

There are a couple of things you can do to make testing software like that easier. First, try to abstract as much as you can into layers that aren't visual. That will let you just write standard unit tests on those lower layers. For example, if you have a button that performs a certain calculation, make sure you have a way to perform that calculation in a ...


5

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


5

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


4

Everything has an interface. When I put my testing hat on, I use a specific world-view to write a test: If something exists, it can be measured. If it can't be measured, it doesn't matter. If it does matter, I just haven't found a way to measure it yet. Requirements prescribe measurable properties, or they are useless. A system fulfils a requirement when ...


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


3

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


3

This is a good question, and FWIW I'll throw in my two cents. About a year ago I was coding in Salesforce, a platform which had an ingrained mechanism which forced you to not necessarily write tests before you coded, but rather forced you to write tests in general. The way it worked was that the system would force you to write tests, and it would make a ...


2

I agree with both Daniel Hollinrake and Ewan, that the first key point why your test-only-if-modify works well so far is: I am the sole developer on my projects and I am responsible for everything and that a likely second key point is: you're producing nice clean code I do not think TDD brings a huge productivity boost for sole programmers, and it ...


2

To make the process work in the long term I would write the tests when the code is being written. Which may seem to contradict your approach. However you've posed the question so I'll give you my take: You don't have to write the tests before the code. forget that purity. However you want to write the tests around that time. Once you have got the code ...


2

For me the key thing appears to be this: I am the sole developer on my projects and I am responsible for everything: Requirements gathering, design, architecture, testing, deployment, etc. I suspect this is why my process is working. This works for you and you're producing nice clean code (I assume!). The only thing I would say you need to do is ...


2

I can't promise that this is optimal, only that it's how I have been handling performance tests with moderate success. Fairly substantial "real-world" integration tests get run under a timer, N repeats per test. Stash the results in a database. Periodically a set of results gets tagged as a waterline and subsequent runs are compared to that one, e.g. for a ...


2

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

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


1

Start with a known file that produces an expected image. Check every pixel. Each should have an expected value for a known, hand-crafted test-file. You should have an expected output-image to compare it against. Anything that's "off" signifies a bug in your code. Expand your test-file so the output image changes and hits every feature of your software. ...


1

Of course it's a thing (it's just unsearchable, because search engines don't handle meaningful differences in word order well). Automation is code that does things you would otherwise have to do by hand. Spoken loosely, that covers all computer programs, so we usually use it to mean "code that generates other computer-readable assets". And of course it's ...


1

There is one drawback: Assigning both tasks in parallel (to two different people) may result in wasted effort, if both end up working in parallel (and reject the change). Consider (measure) how much the two kinds of tasks cost, and how likely they are to result in further changes before acceptance. With those numbers available, you can estimate if it ...


1

I think you're running into a common pain point while testing and one of the reasons I dislike singleton implementations. Injecting these repository instances is a useful pattern allowing you to substitute test doubles or change the configuration of the API client in the future without needing to modify its implementation. However by implementing it as a ...


1

Look at the quality model listed here. Every one of those qualities is non-functional. Functionality that fulfills the business's needs is determined by your functional software requirements. Each functional requirement should be accompanied by an acceptance test, and it is that acceptance test (and not some ISO standards document) that dictates whether ...



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