Ayende @ Rahien

Robert commented on Structuring your Unit Tests, why?

Tue, 10 Jan 2012 21:16:17 GMT

Sorry, but I also disagree. The approach Phil outlined is simple and effective, so why not.

Rey Rahadian commented on Structuring your Unit Tests, why?

Thu, 05 Jan 2012 00:39:24 GMT

whatever works i guess, personally i like Phill's approach on this. It make unit tests more organized and easier to look at when you have tons of unit test on one file

AbelebA commented on Structuring your Unit Tests, why?

Tue, 03 Jan 2012 14:49:20 GMT

I will have to disagree with this one. I think that organizing anything -- whether they be tests, code, you name it -- it's a good thing as long as it doesn't distract from the main purpose.

C Loggins commented on Structuring your Unit Tests, why?

Tue, 03 Jan 2012 13:37:13 GMT

I've used both test methods: using static classes to encapsulate state and more simple structures. It comes back to the idea that code is read a lot more than it's written. Tests provide a way for me to see how the code should work. I agree that tests should stay in place for as long as the requirement driving the test is valid. I don't agree that tests won't (or shouldn't) ever change. For me, it's a cost/benefit thing. If wrapping the tests in a static class makes them easier to read and understand, I'll do it. If not, I won't. Tests aren't just there for an automated runner to ensure things are working well, they're a diagnostic tool and documentation of the code. They're a way for me to communicate to another developer how the code should behave.

Will Gant commented on Structuring your Unit Tests, why?

Tue, 03 Jan 2012 03:22:45 GMT

The most common excuse I've heard/used for not testing is that I can't figure out how to test. The second most common is the amount of time it takes to write and run tests. I think I would keep a pretty bare-bones organization of tests because of the latter case. It needs to be just enough that I don't waste time fiddling with the tests, no more. That said, I'd probably organize the tests according the object being tested, that is, I'd have a class that has all the tests for a given class in the system. I don't think I'd go to the point of having nested classes for each test case. My main use of the unit tests is so I can get the thing to dump out a pass/fail in the console window using TestDriven.net. I find the GUI red/green/yellow test runners to be slow and somewhat visually distracting. The only reason I would want to keep tests together at the object level is so that I can just run the unit tests for the specific type in a batch as I'm wrecking....er.... tinkering with the object (I try to be aware of this because I'm frequently not using top of the line equipment).

Ayende Rahien commented on Structuring your Unit Tests, why?

Tue, 03 Jan 2012 02:20:17 GMT

Bob, To be fair, I know of a fair number of people who go to read the tests first, and use that as a source for information.

Ayende Rahien commented on Structuring your Unit Tests, why?

Tue, 03 Jan 2012 02:19:52 GMT

Daniel, Instead of answering here, I scheduled a post about it, the early access link is here: http://ayende.com/blog/152993/testing-rhino-service-bus-applications?key=ee11d848dadc4923b8de78e6a7813888

Bob commented on Structuring your Unit Tests, why?

Tue, 03 Jan 2012 01:32:03 GMT

>Their only value is their binary ability to tell me whatever the product is okay or not. Brilliant statement. Did anyone ever use them for any other purpose? I wasn't aware they had any other use.

AndyB commented on Structuring your Unit Tests, why?

Mon, 02 Jan 2012 18:18:23 GMT

Ayende Maybe this is me with my BDD hat on, but to me the tests are a representation of your requirements. Therefore if your requirements change, your tests change. Having well organised tests help with readability and maintainability in the same way as it does for production code.

Daniel Lang commented on Structuring your Unit Tests, why?

Mon, 02 Jan 2012 15:23:19 GMT

I probably missed something, but can someone please tell me what the Consume() method does and where did it came from?

jalchr commented on Structuring your Unit Tests, why?

Mon, 02 Jan 2012 13:53:44 GMT

Irrelvant of what Phil is suggesting, I find structuring tests a critical sign of tests readability, which is very important as tests reflect the feature-set you are building. I do use 3 levels of tests: 1) Unit tests: at the class level for Domain objects 2) Integration tests: usually involves a database or external service or file system. 3) UI tests: for asp.net and derived by feature tests. You could argue about why units tests in the presence of integration tests, my answer is test time + fine grained feedback in TDD.

Toni commented on Structuring your Unit Tests, why?

Mon, 02 Jan 2012 12:59:45 GMT

I tend to organize my tests by the use case. The test class name describes what is the use case and the actual test methods tell me what should happen. When the test fails I can see what part of the use case does not work. public class When_order_is_received { public void Then_order_is_saved() public void Then_confirmation_email_is_sent() }

Darren Cauthon commented on Structuring your Unit Tests, why?

Mon, 02 Jan 2012 12:32:09 GMT

If you do TDD, your code is going to naturally be structured against the source code because that's what the tests are driving: what appears in the source code. There are different ways of organizing these tests, like one test class per production class, one class per method, one class per behavior, etc. What's important, though, is that the tests are driving and that they exist.

Ayende Rahien commented on Structuring your Unit Tests, why?

Mon, 02 Jan 2012 12:17:04 GMT

Daniel, That is exactly my point. Doing maintenance over tests is pure waste. They should be write once and stay there, pretty much. Working on tests means not working on other things.

Daniel Marbach commented on Structuring your Unit Tests, why?

Mon, 02 Jan 2012 12:11:51 GMT

I think structuring unit tests not only internally (following arrange, act and assert) but also externally (folder, subclasses or whatever method you use) is utterly important. The larger the project grows and the longer the system is maintained the tests have to be maintaned too. If you apply a small set of conventions for internal and external structure it is very easy for developers who join the project later on or juniors to quickly feel comfortable in the code structure.The is actually a huge time saver and not a waste of time. You gain a lot of time because people don't need to filter and sort the tests again and again with tools help such as resharper. I always treat test code like productive code. Because we spend time writing it so we also must spend time to improve, refactor and cleanup the test code. This applies for unit and developer acceptance tests... Daniel

Nick commented on Structuring your Unit Tests, why?

Mon, 02 Jan 2012 10:42:10 GMT

"Spending a lot of extra time on the tests distract from creating real value, shippable software." I don't see where Phil is spending lots of extra time? He's picked a convention for laying out his tests that others have found to be useful for maintenance and understanding. If you treat them like a dumping ground and chuck things anywhere.. wait, did Ayende really post this?

Craig commented on Structuring your Unit Tests, why?

Mon, 02 Jan 2012 10:34:23 GMT

I don't really think Haack's structuring would require very much more time to implement. One thing I also like about it is it provides a guideline for a team to follow, otherwise everyone naturally ends up following their own approach and chaos follows.

frank quednau commented on Structuring your Unit Tests, why?

Mon, 02 Jan 2012 10:06:43 GMT

well, phil talks about unit tests, while your example is not a unit test. hence, any comparisons may be invalid. personally i find your emphasis more useful for myself as well.

Ben Lakey commented on Structuring your Unit Tests, why?

Mon, 02 Jan 2012 09:39:25 GMT

Structuring the tests in a uniform way requires spending a negligible amount of time. The easier it is for a human to quickly read and interpret tests is a win, so I'm not sure what the downside of organizing the tests in this manner. If the argument is purely that it wastes time, that would seem to only apply if one were altering an existing code base of tests to follow the pattern. Again, the time cost is almost non-existent, so I don't understand the opposition.