Conventions… I have always been keen on asking why we need to follow a convention and is there a better way to do it. This is test name convention is something I have been noticing people following for a long time. When we write test people always tend to name class names and method names sometimes as test and I don’t think that is the right thing to do and here are my reasons why.
I have always been careful in naming things in code. As uncle bob says name is everywhere. We name variables, class names, method names, file names, namespace names but for me test names are really special as I work with them a lot.
As I work I have started to imagine tests as conversation with application or SUT. Lets say we are writing tests for a printer. Normally I have seen tests like
PrinterTest -> shouldPrintOnBothSides
(Now with new NUnit and JUnit the test in method name is dropped and also should is a BDD convention). But the problem with this way of writing tests for me is I am not communicating my expectations on what I am trying to write in the production class. Rather I am expecting the test to do something for me.
Instead of this how I really like to name test is
Printer -> use_both_sides_of_paper_when_configured
I tend to use snake casing rather than camel casing when possible even in C# or Java as it is more readable. Also I use the same production class name for the test class name as I feel this shows my intent of expecting and conversing with the production class (I also feel there will be high cohesion inside a test). I don’t think naming the two classes as they are in two different namespaces or packages. So if I need to use Printer class here I use it as Impl.Printer. It is a small trade off I need to make for the intention revealing tests I can write. I also don’t use lots of should in test names as it becomes too imperative for me.
Sometimes when I am writing a class and I expect it to return or do something something I tend to write it as
Printer -> give_me_no_printout_when_I_give_print_and_you_run_out_of_paper
That’s my way of writing tests. Let me know if you like it or otherwise and please discuss the reasons. For the last set of posts I have been people replying I don’t agree with you but missing why. I would love to hear the reasons from you as well :).
Confusing title… I know. I am good in making such titles :).
This is for people who when they mock something call it as mockXXX. It is a convention with a lot of people even me till a few days back. I moved away from the keboard and saw that the code was having too much of mock naming noise. I started wondering why do we do that and started talking to people. Some of the replies I got and my opinion on them is the root of this post.
- It is a convention - My way is if the convention doesn’t make any sense or add value don’t follow it.
- When I read my test I will know which is mock and which is not - My opinions on this are
- I don’t care if it is a mock or the real object. I just want the behavior I want. As long as the behavioral requirement gets satisfied I don’t think I care. Is there any other reason?
- A good unit test should be short and crisp. So when reading a test it will be easy to spot out mocks if there are any.
- I am not really a dogmatic advocate of anything except being aware of the context and basing decisions on that. If using the real object makes more sense than mock go ahead use it.
Basing on these reasons I don’t feel that it is good to pollute the test code with mockFileReader, mockDataProvider statements. Use meaningful names which make the test readable.
I think I also don’t like to name interfaces as Ixxx. But that is for a different post :)
I am not sure why but whenever the topic is testing it is always about testing the application or writing test code. Both are really good and are important part of software development but there is more to testing than automation and testing the code.
I see testing to be a perpetual activity in an iteration and not as a phase. We do different kinds of tests and we may not realize it most of the time. Some tests test what we have built and some test our understanding of what we are trying to build.
The tests which test the software help us in finding if the expectations are met and if we have broken an already existing expectation. These tests include exploratory tests of the application, automated tests,These tests are good in catching defects as well in regressing to see if any expectation has been introduced.
Tests which test our understanding help us in flushing away assumptions. These are subtle tests which we may not realize. They include the example writing workshops, wire frames, mock ups, prototypes, discussion with customer, architects and other team members. These tests are good in preventing defects as they bring common understanding across the team and clears away assumptions.
There are tests which span between these two kinds like acceptance tests in ATDD sense. In the 4D activities (Not phases :), the first two as well the last (Discuss, Distill) are of the testing our understanding kind. The third (Develop) is of the testing if expectations are met kind.The last one Demo is partially on both kinds.
The advantage of testing the understanding kind is their immediate value in terms of feedback is high. They help you in minimizing waste. But over the period of time they may get lost. So it is important to crystallize them by converting them into tests of second kind. Like converting the examples we discuss and distill with the customer into acceptance tests. The testing the expectations kind have more cumulative value than immediate value.
What is common in both kind of testing is the feedback.
So when we talk about testing it is not just about testing application, it is really about feedback which can improve the product. And the feedback can come from different form of tests we do. Some help us in doing the right stuff and some in doing corrections to what we have already done.
Just my understanding of the concepts
f(x) = 4(2x + 3)
g(x) = 8x + 12
So f and g are same functions or procedures?
Function is an abstract concept mapping input and output. Input goes into the box and output comes. If for the same input pushed into two different boxes produce give same output they do the same function.
Whereas the procedure is an algorithm. They are implementation concepts and it defines the way we process the input to output. So f and g even though they give same output for same input do it differently and they are different procedures.
And here is Naresh Jain’s more programming world oriented definition of the same concept which I agree to http://tinyurl.com/cf6so2
That’s all for today people :)
This post is my view on using ActiveRecord classes as domain classes. I have been using rails for quite sometime and have seen this pattern of creating a class and extending it from ActiveRecord::Base every time we think we need a domain class. I am not really comfortable in doing this and following are the reasons why
- I want my domain logic to be free of persistence stuff. Even though ActiveRecord hides it down the inheritance chain the domain class still gets this capability. I want my domain classes to be clean of this and only concentrate on domain logic.
- I think in seperating responsibilities of domain logic and presistance data mapper patterns is a better choice than ActiveRecord.
- I think the domain layer should care only about the domain rules and shouldn’t care how I do my persistence.
- Testing your model seperate is pain as ActiveRecord expects a table of the same name as class name else will throw an error. There are ways to by pass this by meta programming magic but why do we need to do it.
The problem I see with ActiveRecord in rails is it literally creates these classes and puts them in a model folder. The model generator as well hiding most of the stuff behind inheritance hierarchy also doesn’t help much in highlighting this fact to the developer.
I feel that for complex domains it is necessary to have a clear separation between what my domain rules and workings are from how I am persisting.
I may go for the ActiveRecord class being a part of domain layer when my domain is really anemic and has very less rules other than CRUD stuff. What are your thoughts on this.
Keep the model clean of the infrastructure code. It helps in a long run.
