Pragmatic developer

I had had a problem with preparing input data for tests. I am looking for the best way for it, because this is problematic. Why? I tell you something about it and my mistakes. The ways which I tried All in tests/suite I want to tell you about my first solution. I read about good tests and I often read that on the tests should be prepared always only on a test or suite tests. This is a good point, because when I read these tests I know what I have in input. I shouldn't search information about it. I think you agree with me that You have all on this place when you need to check why the test is failed. Minuses are two in this solution. First is a lot of copy paste code. If you don't have a problem with duplicate code, you never refactor your code or change functionality. After these actions you always need fixes a lot of tests where you use that object. Sometimes you can use replace feature on your IDE, but when you create a product with other people, I am sure You will find

Do you think sometimes about how organize your code? I think about it a lot of time, when I have time to analyze it. I don't know how you, but I sometimes think that private is all what we don't use on another space of code and public is whatever what we used. It is organized without thinking about what the function does. The problem is when we want to test that function. If you have public is easy to test, but when you have a private function my question is why you want test it? Maybe it should be public or package private? As you see I had a lot of questions. I will show you my answers for it. Access modifiers As you know well, we have four access modifier (in Java): private, package private, protected and public. A private is only class access. A package private is for class and package, but doesn't for subclasses. A protected the same as package, but with subclasses. A public is access for all. I am showing you these just for the reminder. My previous wrong wa

As I mentioned, I would like to tell you something about Mockito on unit tests. You should know about where use unit test, because I will use that context for this post. What Mockito is? I changed my thinking about Mockito object and this step allows me to use it only in a good place for it. I think about Mockito objects only like data source (on "given" section) and communicate with other system (on "then" section). Why? Because I think when you use a lot of Mockito objects, you don't have a single responsibility in testing code. You use mock or stub for a lot of objects, because you think that part of the code isn't currently important. I don't think that it doesn't important if you have on that method. Maybe it should be another function in another place. When you think like me, You will use it only for a really important place for it. What can I stubbing? As I mentioned You can stubbing data sources. This is a good place for it, because Y

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 syste

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,