Where use unit test?

By -

I wanted to make a post about Mockito, but I think the answer for title questions is the necessary knowledge before it. So what do you think about it? All code should be tested or only core? I have my option about it and I share it for you.

I don't test all code using unit tests

I begin from the easier sides. I don't test getters and setter, because it is stupid. If you don't use setters or getters on your methods, maybe you don't need it. Sometimes of course you use the library which map an object using reflection, so You must have these data only for storage. I know, but in other cases you test your getters and setters during testing functionality which using it.

A unit tests are bad for facade implementation, because I think this is a good place for integration tests. Why? Integration tests are for check how components working together. If you want to check how methods work together I feel you want to do the same.

The next place is integration with other systems and application. That place is for integration test too. If you have the possibility to use the other system for testing I think You should use integration tests. In these places you should only test create data for it or feedback services, but single responsibility tells us that it will be other functions.

The last fragment is configuration, because we can't test it other than copy paste it.

Only these fragments of codes I skip. Do you think there was a lot of code for testing. I think NO! A lot of our code only uses blocks which should be tested using unit tests. Maybe in other projects than a web site application is more testable code, but in this way I think a lot of code is only facade and we do not even realize it.

What you should test like unit

An algorithm for data processing on globally meaning. If you filter data, sort, find and etc. You should test it like unit. This fragment of code is a very sensitive to bug. Another case is data preparation and service. That is less sensitive to bug, but It is your business logic, so it is important.

A business exceptions should be tested, because you should be sure that it work fine and you do it on exception case. 

Conditions are good fragments for testing, because being problematic and sensitive to bug.

Validators, operations on objects, data generators and utility functions.

What you can test like unit for a greater good

You can test a library for understanding and be sure what it works. This is good practice if you have time or if you want check it. If you have that tests you can calmly upgrade it when your tests working fine. A lot of programmers and company don't have time for it, but if I can do it, I will do it. 

For the end.

If you have any question about a specific fragment of code or about how testing feel free put the question in the comment.

Comments

Post a Comment

Popular posts from this blog

My mistakes in working with legacy code

By -
Image
Hi everyone. A little bit time before, I have to work with legacy code. I need to extract the two from a lot of functionality. Of course the other functionality can work too. I need only change the way how it works and replace a kind of connection to database, servers and other applications. I made a mistake and I want to share my conclusion for it. How will I do it today? I will get a knowledge. I will get the use cases. I will validate the knowledge with the code and the use cases. I will change only fragment of code, where I must change. The end. Why? Get a knowledge I started from getting a knowledge from my colleague. I ask a lot of questions, get information about core functionality and what they want. If you worked with legacy project you know that knowledge is very poor. My first mistake was I didn't verify that knowledge in the code. I started working with code and three days later I got the blocker. I couldn't do it like I wanted, so next time I will try t...
Read more >>

How correctly imitate dependencies?

By -
Image
This is continuous of my previous post about why we should imitate our dependencies. I did it not long ago. I though about how do it properly and when I can say that it is correct. Start from test and real dependencies I am starting from the tests. I wrote the simple tests which, I though, are correct. That was my learned about dependencies. I had the good situation that I had some prepared tests before. During the writing test I got a knowledge. A lot of time, I verified what the system return. After it, I got the full automated tests for my dependency. Now, I am sure that dependency works like I think. Like my test use it. I think this is a very good advantage. Extract the interface for communicating The implementation to communicate is implemented and tested. Our test, if you implement it like functionality test, not code test, should show us, how we want to use our dependency. We know what parameters we use, what methods. We know what we want. That is a place where we must extr...
Read more >>

Why TDD is bad practice?

By -
Image
Did you listen that TDD is bad? What do you think about it? I have my opinion about it! TDD is bad because... We don't have time to write tests first - I think this is a good point. I sometimes don't have time for that. Why? Because I need to do quickly fix on our code and deploy it. In this case I don't have time to create test after wrote production code too. The even worse case is when we have tested this part of our code and test after change doesn't work. I don't like this, because I must read tests and thinking about repair tests for new logic. I really don't like this. I would like to create new test and remove old every time when I have that situation. What's wrong with the test first on this case? Nothing, because if you have time to write tests after create code, you have time to create test before it. Don't you think so? We know how will implement it, but we don't know how testing it - I think a lot of developers have this problem,...
Read more >>