Win a copy of Real-World Software Development: A Project-Driven Guide to Fundamentals in Java this week in the Agile and Other Processes forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Bear Bibeault
  • Liutauras Vilda
  • Devaka Cooray
Sheriffs:
  • Knute Snortum
  • Junilu Lacar
  • Henry Wong
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Tim Holloway
Bartenders:
  • salvin francis
  • Frits Walraven
  • Piet Souris

Help with Junit

 
Ranch Hand
Posts: 539
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have the following classes.






The test keeps failing, but I don't know why! I've tried printing the contents and they seem to be exactly the same. Please help!
 
Saloon Keeper
Posts: 11462
247
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The obvious question is, does Transaction override equals(Object) and hashCode()?
 
Prasanna Raman
Ranch Hand
Posts: 539
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No it doesn't! Forgot about that. So it looks like it's needed only to make tests pass, and not for much else.

Is it a smell that I am adding code to make a test pass?
 
Stephan van Hulst
Saloon Keeper
Posts: 11462
247
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The simple fact that you expected two transactions to be comparable like that should tell you that it's reasonable to do, even if your application doesn't directly use it (yet). Principle of least surprise, and all that.
 
Sheriff
Posts: 15020
251
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Prasanna Raman wrote:Is it a smell that I am adding code to make a test pass?


Glad to see that you're thinking about smells coming out of tests. While I'm sensing a few smells, they're along different lines from what you're thinking.

Having to override equals() and hashCode() is necessary since it relates to the semantics for the Transaction class. The fact that a failing test pointed to that issue is actually a good thing that you should celebrate because you've demonstrated the usefulness of tests in finding design flaws (yes, not properly overriding equals() and hashCode() is a design gap). This will add to your experience with tests and should strengthen your belief that TDD is an indispensable design tool. For all these reasons, great job!

Now, the basic (tactical) smell I'm getting is your use of Lists. Your assertion that the two lists should be equal is smelly to me for the following reasons:
1. You're making an assumption as to the order of items being added to the output list.
2. The name shouldConvertInputListToTransactionList doesn't say anything about the order of items in the list being the same order of the input strings.
3. You don't have a test that explicitly documents the behavior around order of input vs. order of output

All of the above means that someone else reading this test also has to figure out there's a 1:1 order relationship between input and output. Without a test to explicitly document this, someone like me might think this was just a happy coincidence.

I'll post a separate reply to show what I would do. Also, there's another bigger but more subtle smell which I'll explain in a separate post.
 
Marshal
Posts: 7486
509
Mac OS X VI Editor BSD Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Few coding style points.

1. Transaction really supposed to be an immutable thing. Once it is created, it couldn't be modified afterwards. Having said that, customerId, timestamp and ammount could be passed through constructor and so you could get rid off those setter methods completely. Class become smaller, easier to understand.

2. convertStringToLocalDateTime() -> stringToLocalDateTime() - I personally would prefer the latter. You want code to be expressive enough and not too verbal at the same time. That's not always an easy task, but think about it.

3. Make InputFormatterUtil class final (always make all classes final by default, unless there is a different need) and add private constructor, so nobody by mistake would instantiate it.

4. Learn about Java Streams API and see if you could re-work createTransactions() method in order to have it written in declarative style as oppose to imperative.
 
Prasanna Raman
Ranch Hand
Posts: 539
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:

Prasanna Raman wrote:Is it a smell that I am adding code to make a test pass?


Glad to see that you're thinking about smells coming out of tests. While I'm sensing a few smells, they're along different lines from what you're thinking.

Having to override equals() and hashCode() is necessary since it relates to the semantics for the Transaction class. The fact that a failing test pointed to that issue is actually a good thing that you should celebrate because you've demonstrated the usefulness of tests in finding design flaws (yes, not properly overriding equals() and hashCode() is a design gap). This will add to your experience with tests and should strengthen your belief that TDD is an indispensable design tool. For all these reasons, great job!

Now, the basic (tactical) smell I'm getting is your use of Lists. Your assertion that the two lists should be equal is smelly to me for the following reasons:
1. You're making an assumption as to the order of items being added to the output list.
2. The name shouldConvertInputListToTransactionList doesn't say anything about the order of items in the list being the same order of the input strings.
3. You don't have a test that explicitly documents the behavior around order of input vs. order of output

All of the above means that someone else reading this test also has to figure out there's a 1:1 order relationship between input and output. Without a test to explicitly document this, someone like me might think this was just a happy coincidence.

I'll post a separate reply to show what I would do. Also, there's another bigger but more subtle smell which I'll explain in a separate post.



Thank you Junili. Can you elaborate on the other smells that you are referring to?
 
Prasanna Raman
Ranch Hand
Posts: 539
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Liutauras Vilda wrote:Few coding style points.

1. Transaction really supposed to be an immutable thing. Once it is created, it couldn't be modified afterwards. Having said that, customerId, timestamp and ammount could be passed through constructor and so you could get rid off those setter methods completely. Class become smaller, easier to understand.

2. convertStringToLocalDateTime() -> stringToLocalDateTime() - I personally would prefer the latter. You want code to be expressive enough and not too verbal at the same time. That's not always an easy task, but think about it.

3. Make InputFormatterUtil class final (always make all classes final by default, unless there is a different need) and add private constructor, so nobody by mistake would instantiate it.

4. Learn about Java Streams API and see if you could re-work createTransactions() method in order to have it written in declarative style as oppose to imperative.



Great inputs, thank you. Please look at the below and comment.



I've made the other changes as well.
 
Junilu Lacar
Sheriff
Posts: 15020
251
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let me start off with the bigger but more subtle smell that often gets overlooked. This one has to do with the name InputFormatterUtil.

What's smelly about it? Well, it's a misleading name at best. At worst, it just an outright lie. The fact that it has "Util" in it should make it suspicious anyway. That was my first reaction. A suffix like "Util" or "Helper" in a class name is often a sign that the purpose of the class was not really clear or that it's just a bucket for things that aren't really related to each other in any significant way, at least not in an OO sense.

In this case, there's at least a misalignment with what the name implies and what the code actually does. What the code does is it extracts values from CSV and creates a Transaction based on those values. That's parsing, not formatting. It could also be considered as unmarshalling but then you'd need a corresponding marshalling process for symmetry. From what I have seen in general, classes that have parse() methods usually have toString() methods that are symmetrical. For example Period.parse("P1Y2M21D").toString() and LocalDateTime.parse("2014-12-15T15:45").toString() give back the original String value. (Ironically, I'm not really sure "symmetrical" is the right term to use here so if anyone has a better term please suggest it).

Since the code is actually parsing (or unmarshalling) CSV into a Java object (a Transaction), "InputFormatter" is not a good name. This may seem trivial and nitpicky but it's really a key design decision. Remember, choosing good names is considered one of the two hardest things in programming. Never take it lightly because starting off with a poor name choice often leads you down a road paved with even more poor decisions because of a lack of clarity of purpose.
 
Prasanna Raman
Ranch Hand
Posts: 539
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Junilu. Great advice, I always struggle with coming up with names for these things that deal with formatting and preparing input. So what would be a good name for it?

InputParser?
 
Junilu Lacar
Sheriff
Posts: 15020
251
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Prasanna Raman wrote:I always struggle with coming up with names for these things that deal with formatting and preparing input. So what would be a good name for it? InputParser?


We often make this harder than it needs to be by ignoring 1) precedents and 2) the obvious.

It seems like you've developed an attachment to "Input" being part of the name. Why? Is there anything particularly special about the input? On the other hand, why are you leaving out the fact that there's a domain class, Transaction, that's central to this? Wouldn't the obvious choice of name be TransactionParser?

As for precedent, you have a least one in the standard API: DateTimeParser -- which takes Strings and parses into DateTime objects. From this example alone, you could reason that TransactionParser follows this precedent better than InputParser would.

Don't feel too bad though, I've seen this kind of thing many times, even from experienced developers. Choosing good names is as much an art as it is a skill and it takes a lot of practice and experience to really get good at it.

One thing that really helped me was just "telling the story" of what the class does. When you can do that clearly and with as few words as possible without losing clarity, then you'll usually have a handful of words that you can choose from to make a good, intention-revealing name. For this particular class, the story is that it "parses CSV into a Transaction object." See how the answer actually stares you right in the face? You just have to know how to look. Actually, when you're telling the story, the key is knowing what to listen for.
 
Junilu Lacar
Sheriff
Posts: 15020
251
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Once you start thinking of better names and settle on something like TransactionParser, the next thing I would think of is simplification. Having a separate class just for parsing from CSV certainly might be justified but is there a simpler approach? Again, I look for precedents. I already pointed out a couple: Period and LocalDateTime both have parse() methods that are symmetrical to their toString() methods. Would it make sense to have a Transaction.parse() method that is basically the reverse of Transaction.toString()? That is, Transaction.parse(someString).toString() will give back someString.

If this works for now, then I'd probably prefer going with this design until something tells me that I need an entirely new class to encapsulate the Transaction parsing functionality. Would this result in simpler tests? I'm guessing it probably would.
 
Prasanna Raman
Ranch Hand
Posts: 539
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you. In regards to putting the method in the Transaction class, the only question I have is whether a model object can contain a method like this.

One other question regarding the name: The class is actually parsing the input STRING and converting it to Transaction. Is it still OK to call it TransactionParser?

 
Junilu Lacar
Sheriff
Posts: 15020
251
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Prasanna Raman wrote:Thank you. In regards to putting the method in the Transaction class, the only question I have is whether a model object can contain a method like this.


That's a good question but let me ask you this: What is telling you that it would be a bad choice to do so?
 
Prasanna Raman
Ranch Hand
Posts: 539
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:

Prasanna Raman wrote:Thank you. In regards to putting the method in the Transaction class, the only question I have is whether a model object can contain a method like this.


That's a good question but let me ask you this: What is telling you that it would be a bad choice to do so?



Actually, nothing! Just that I've not really seen tests being written for model classes. So it got me wondering, but if you think that's good, then I am happy to go along with that!

Also, I wanted to get some advice regarding package names. I get confused whether it should be singular or plural. Here are my package names so far:


 
Junilu Lacar
Sheriff
Posts: 15020
251
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Prasanna Raman wrote:The class is actually parsing the input STRING and converting it to Transaction. Is it still OK to call it TransactionParser?


Again, you're ignoring precedents. Look at Period.parse() and LocalDateTime.parse(). What do these parse() methods have in common? They take a String value. A parse() method will generally be expected to take a String as its input. Symmetry is important in programming. It creates consistency and makes your code more intuitive to use.

Period.parse() takes a String and produces a Period object
LocalDateTime.parse() takes a String and produces a LocalDateTime object
Therefore, Transaction.parse() takes a (what?) and produces a (what?) object

I'm sure you can fill in the missing pieces above to follow the pattern set by Period and LocatDateTime.
 
Prasanna Raman
Ranch Hand
Posts: 539
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Makes total sense!
 
Junilu Lacar
Sheriff
Posts: 15020
251
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Prasanna Raman wrote:but if you think that's good, then I am happy to go along with that!


That's probably the worst reason for going with any design choice. There has to be a better reason than someone (especially me!) thinking it's a good way to go. At the very least, you either agree or disagree with the reasoning I gave. That means you've actually considered the reasons and made your own choice based on your evaluation of those reasons.

Actually, nothing! Just that I've not really seen tests being written for model classes. So it got me wondering,


If you haven't seen tests written for model classes, then you haven't seen good tests. Most unit tests focus on domain objects.

Also, I wanted to get some advice regarding package names. I get confused whether it should be singular or plural.


Again, look for precedents that you think would make your choice one way or the other more consistent with what most people would expect to see. Use the POLA (Principle of Least Astonishment) as your guide.
 
Junilu Lacar
Sheriff
Posts: 15020
251
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just so you know, I have enough experience that I can usually make good design choices almost intuitively (or so it may seem). But even I don't trust my intuition because even with as much experience as I have, I can still be wrong!

Experimentation. That's the key. The code will always tell you which way it wants to go. But again, you have to know what to look for (or listen to). The tests will help you listen to the code/design. If the tests are easy to write and they are expressive, that tells me the code is happy to go where you are going. If the tests are hard to write, are complicated, or don't tell a good story, that could be the design trying to tell you that it wants to go a different route. I know this may sound strange (even weird) but it's the best way I have to describe my relationship with tests and how I use them to help me arrive at better designs. Put in another way, the tests tell me whether I'm trying to force my will on the design or if I'm helping the design emerge and evolve to what it wants/needs to be.
 
Prasanna Raman
Ranch Hand
Posts: 539
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:That's probably the worst reason for going with any design choice. There has to be a better reason than someone (especially me!) thinking it's a good way to go. At the very least, you either agree or disagree with the reasoning I gave. That means you've actually considered the reasons and made your own choice based on your evaluation of those reasons.



Sorry, that's what I meant. It does make sense to me, and because I don't have experience thinking like this and because what you have said makes sense and seems logical now that I understand it, I meant to say I'll along with this approach
 
Junilu Lacar
Sheriff
Posts: 15020
251
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Two quotes, both attributed to Albert Einstein:

The intellect has little to do on the road to discovery. There comes a leap in consciousness, call it intuition or what you will, and the solution comes to you and you don't know why or how.


A new idea comes suddenly and in a rather intuitive way, but intuition is nothing but the outcome of earlier intellectual experience.


They seem contradictory but my guess/hope would be that the first came before the second.
 
Junilu Lacar
Sheriff
Posts: 15020
251
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's a great quote:

Jon Kolko wrote: What many refer to as intuition, then, is not the untaught or unteachable but instead is a learned understanding and respect of process, molded by experience and refined over a great deal of time and practice.


If you're wondering why I keep harping on intuition, it's because

You wrote:... I don't have experience thinking like this


So it's important to practice thinking like this so that you can start seeing some of these things, too. That kind of insight or intuition, as Einstein and Kolko said, is nothing but expereince and learned understanding. Another way to look at experience is that it is "what allows you to recognize a mistake when you make it again." To me, that means that the more experience I have, the more mistakes I've made. And that's actually a good thing.
 
Prasanna Raman
Ranch Hand
Posts: 539
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for all the great inputs, Junilu. Are there any books that you recommend that can help me get past this rut?

I feel that in terms of coding style, I seem to have decent practices, but when it comes to design, my development has been very slow. Lack of professional opportunities has been a major factor as well, but I'd like to improve from being an average developer to one that can identify smells and make good design decisions regardless of the type or the domain of the problem, like some of you in this very forum seem to do very well.

Any suggestions would be appreciated!
 
Junilu Lacar
Sheriff
Posts: 15020
251
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a few personal things to take care of so I won't be able to post follow-ups for at least a couple of days. In the meantime, however, I would advise you not to consider whatever your current state is as a "rut." That makes it sound like you're not making any progress, which isn't true. It's all part of your learning journey and as long as you're learning something new every time you do something, that's progress and therefore not a rut.

In my experience, once I learn about mechanics (how), I focus on principles (why). If you understand the reasons behind doing something (or not doing it), then it's easier to apply that understanding to other similar situations. It's all about patterns and pattern recognition. Each instance/case may be unique but if I really try to dig deep into an issue to find the related principle(s), then I can usually figure out what the best course of action is to take. Again, it takes a lot of practice and making mistakes so having a growth mindset that treats mistakes as opportunities rather than setbacks or impediments is very important.
 
Junilu Lacar
Sheriff
Posts: 15020
251
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, so taking a break from the tedious, mind-numbing, patience-trying, and soul-crushing chore of preparing taxes.

This:

While that may look good, I've developed a bit of a distaste for this style of test. Yes, it's short but is it really sweet? Besides the problem with some implicit assumptions that I've already pointed out, the more subtle smell here is that of a little too much abstraction. To see what I mean by that, ask yourself "Does this test tell its story with just enough (that is, not too much or too little) detail?" There was a time where I would have written this kind of test, too. In fact, you might have even arrived at this code through refactoring/extract method which is typically how I would have ended up with this kind of code. I might have even carried it further and eliminated the temporary variables:

And since InputFormatterUtil is the class under test, I can use a static import to clean it up a bit more:

That's still too generic though; there's just not enough detail to give me a good sense of understanding of the code. Reading that test would still make me curious about some details. I'd definitely be looking for what the getExpectedOutput() and generateInput() methods produce. As a reader of code, I want a different experience.
 
Junilu Lacar
Sheriff
Posts: 15020
251
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So here's what I'd probably do. (Caveat: I haven't actually done TDD on any of this code, so take all of it with a grain of salt and just imagine I did do proper TDD on it)

To give the reader the experience I would want to have with the code, I refactor and rename a few things so the test gives me a little bit more context:

Now we're getting somewhere. That name is still a mouthful though. I'll rename it to something more pithy and consistent with its behavior/intent:

Looking at that now, I feel like there's quite a bit more context given to the reader. They now know the input is CSV. They know the expectation that the order is maintained. They know they'd be getting back a list of Transaction objects. And they know to use the parseAll() method to do this.

I still want the reader's eyes to be able to make one pass from top to bottom without too much backtracking, just as they would if they were reading a good article. If I'm using JUnit 5, I'd try isolating this more with nested classes. I'd also use a fluent assertion API like AssertJ (or Hamcrest) and do a little bit more refactoring:

You might wonder about duplication now. In tests, I've come to think that having some duplication is fine if it makes creating context for the reader with just enough detail easier. The main goal for tests is to help the reader quickly understand the intent of the code. If some duplication helps them focus their attention on smaller sections of code to digest at a time, I'm willing to take the small hit it takes to make changes in multiple places (until I'm not, of course).

Go back to your original test code and see if you can get an understanding of the code's intent with a single top-to-bottom scan. I couldn't. I had to read a bit, then skip down to an extracted method, then go back up, then down again, then back up again.
 
Prasanna Raman
Ranch Hand
Posts: 539
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Junilu,

Thank you again for the excellent feedback! I am not quite sure I understand the Junit5 version well enough, but I totally understand how what you've written improves readability.

I am trying hard to improve on that aspect, but beyond a point I feel I struggle for more ideas to further improve it!
 
Junilu Lacar
Sheriff
Posts: 15020
251
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It will come with practice so just keep practicing. There are no shortcuts, just as there are no shortcuts to becoming a marathoner or champion tennis player or accomplished musician.

Again, some of the key things are mastery of the medium which in this case is the Java language, the tools (your IDE and different frameworks), and the theories and principles. Combining all these with the skill you gain from practice and experimentation is what eventually emerges as your "style" of programming. If you follow the different regulars here at the Ranch and carefully examine the code they post for patterns, you'll start recognizing what I mean. Everyone has their own particular way of using the language and putting elements of theory and practice together to express their ideas for solving problems. Even beginners can have their own "style" so to speak, however chaotic and messy that may be.
 
Junilu Lacar
Sheriff
Posts: 15020
251
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If I were to say what one thing has really driven my development as a programmer forward, I think I'd have to say it has been trying to answer the question "How do I make this code tell its story better?"

The answer is different things at different times, in different contexts. The possibilities of getting it right are infinite. The problem is, so are the possibilities of getting it wrong. Therein lies the challenge.
 
Junilu Lacar
Sheriff
Posts: 15020
251
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think many people limit their progress because they are looking for the answer to the wrong question. Beginners in particular are interested mostly in answering the question "How do I get this code to work?" which is, of course, necessary. However, it's really just the first step and probably the smallest step forward because it only satisfies the needs of the user who will use the running program. If you never look past that end user and forget about one of the most important users of the code, the person who has to read and maintain that code in the future, you're not likely to progress beyond a certain point as a programmer.

The next maintainer of the code has needs, too, and if the code you write doesn't satisfy those needs, then you're not only doing that person a disservice, you're also limiting yourself as a programmer. The more you think about the next programmer, the better you get as a programmer. It is the gift that keeps on giving and giving back, especially when the next programmer, perhaps a few weeks, months, or years in the future, is yourself.

It doesn't stop there either. Next you'll want to think about other people in the software delivery chain: the testers, the business people, product sponsor (the $$$ guy), the production support people, customer service people, systems administrators, the end users of your end users, your community, your city, your country, the world, and so on. The limit is the extent to which you believe the Butterfly Effect can go. That and the time and effort we each put in. I like how Jeff Patton puts it: Your job as a programmer is to change the world. That's pretty powerful but also a great responsibility.
 
Marshal
Posts: 67976
258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The trouble with the butterfly effect is that is it neither possible to verify nor refute it as a concept.
 
Junilu Lacar
Sheriff
Posts: 15020
251
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:The trouble with the butterfly effect is that is it neither possible to verify nor refute it as a concept.


That kind of misses the point. "The extent to which you believe ..." -- if I believe any effort I put into my code only affects the end user, that's the limit. If I believe it affects only the next programmer, that's the limit. If I believe it affects only the testers after that, that's the limit. If I believe whatever I do here in the Ranch could potentially help someone who has no access to water in Africa, well, there's probably no way to refute or verify that but I don't think it's beyond the realm of possibility. Whether or not it actually does isn't under my control but what I do with that belief is. That's how I believe it works.
 
Campbell Ritchie
Marshal
Posts: 67976
258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:. . . . That's how I believe it works.

And there is a difference between the butterfly effect and what you are saying about your code. I can readily find evidence for your assertion if I go to the people who use your code. If I ask a tester whether Junilu's code is easy or hard to test, that answer will form part of the evidence.
 
Junilu Lacar
Sheriff
Posts: 15020
251
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The belief in universal connectedness is not uncommon. The Butterfly Effect, Six Degrees of Separation, No Man is an Island, heck, even Quantum Physics has entanglement.

If I write code that's easy to test, then some tester just might have enough time in their day to volunteer to do charity work to make clean water accessible to some remote villager in Africa. There's no way to verify that but it's not beyond the realm of possibility, even if you insert a few or a thousand intermediate steps in that chain.

Again, what happens after my actions is not under my control. My actions are and my belief in the extent to which they can affect people is what guides them. Don't get me wrong, I don't do refactoring with the express thought of saving someone's life. I just know, in my heart, that if I do a good job it's going to help not just the next person who reads my code, but others beyond that too, somehow, eventually.
 
Ranch Hand
Posts: 514
10
Android Open BSD Slackware
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:The belief in universal connectedness is not uncommon. The Butterfly Effect, Six Degrees of Separation, No Man is an Island, heck, even Quantum Physics has entanglement.

If I write code that's easy to test, then some tester just might have enough time in their day to volunteer to do charity work to make clean water accessible to some remote villager in Africa. There's no way to verify that but it's not beyond the realm of possibility, even if you insert a few or a thousand intermediate steps in that chain.

Again, what happens after my actions is not under my control. My actions are and my belief in the extent to which they can affect people is what guides them. Don't get me wrong, I don't do refactoring with the express thought of saving someone's life. I just know, in my heart, that if I do a good job it's going to help not just the next person who reads my code, but others beyond that too, somehow, eventually.


Great post
Names are really important in general, but when there is a test involved is a great occasion to make the test following some documentation. I would advice in an ideal world to have utility classes that are without real business logic, of course if are used by more classes has sense, otherwise they should be inside the so called use cases,  acquiring a decoupling nature from the frameworks. The point is that I would name the test with abstract not technical terms, but due to the nature of Utility classes this cannot be achieved, so in this case in my opinion should be the code that speaks and since the scope of every test is really small, names should be really long, especially to describe a behavior if a mock is used
 
Campbell Ritchie
Marshal
Posts: 67976
258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:The belief in universal connectedness is not uncommon. The Butterfly Effect, Six Degrees of Separation, No Man is an Island, heck, even Quantum Physics has entanglement. . . .

But is there any evidence for them all?

If I write code that's easy to test . . . what happens after my actions is not under my control. . . .

Agree. You can find evidence for that. You can verify the truth of that assertion.
 
Marshal
Posts: 25150
64
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:Again, some of the key things are mastery of the medium...



And later you mention some concepts related to that idea. People in my generation read and re-read Zen and the Art of Motorcycle Maintenance to reinforce our belief in the value of quality. You may find it interesting if you hadn't already heard of it.
 
Prasanna Raman
Ranch Hand
Posts: 539
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for all the great posts! Any books that you all recommend not just for testing but to improve the overall design thinking as a developer?

The ones I've read so far are

Clean Code
Refactoring (parts of it)
Effective Java
 
Junilu Lacar
Sheriff
Posts: 15020
251
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Those are all great books to start with. I also recommend Corey Haines "Understanding the 4 rules of Simple Design" available on Leanpub.com
 
Prasanna Raman
Ranch Hand
Posts: 539
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Junilu. You had said you'd be unavailable for a couple of days, are you back now?

I'd like you to review another piece of code that I'm writing. I'll post it another thread when you're available and maybe Stephan as well.
 
Message for you sir! I think it is a tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!