Author: stlplace

This is a continuation of my earlier post of Tree, recursive function and my dumb mistake. As I said in my last post, my solution was to create hash maps (singleton) to store those for the session. The main motivation was to help out the performance. But I found out it backfired on me, a few days ago and today. In both cases, it has to do with the hash map I created, it was something like (object , a list of objects). In both cases the list of objects was actually dynamic, and I made an assumption it was static. In other words, I thought I only need to put the mapping to the map once, then I can use it happily ever after. I think there might be ways to get around it, i.e., I should update the map when that list does change. I will investigate and work on it more. (Update 05-30-14) So I found a solution to one scenario, I was able to update the map as needed. And I use put method (java hashmap) to do that update.

Related articles

• Singleton Design Pattern- Java Tech Guy must read!
• Singleton Design Pattern – An Introspection w/ Best Practices

So I was able to fix that performance problem I mentioned in my previous post. But I inadvertently introduced a new problem in my previous fix. And here is the gist of how I did:


while (some condition) {
if(some other condition) {
...
return;
}
}


Guess what, I was able to put it into infinite loop…I can explain more if needed 🙂

Tree data structure is fairly common in software development, and luckily I have quite a bit experience working on those in my career. I started working on this as I was working for UGS/Siemens PLM Software, and I was involved in the development of XML based data adapter for CAD data exchange, a key piece of information we want to translate is the assembly information, or product structure, or in computer/software terms, the tree hierarchy. I did learned a few things on recursive function, etc. Interestingly enough, later on I got a interview phone call from Google, and the guy asked me about recursion, for a simple problem like this: basically they are 100 matches, every time one can take one or 2, how many combinations are there? I said let’s do it in recursive fashion, after quite a bit reminder/hint, finally I said n(100) = n(99) + n(98)

But they were not very impressed with me, as I did not come up with the solutions fast enough, which is fine. I am who I am, I can work on those kind of interesting problems, in my own pace. Or explained in my Chinese name, it’s getting faster gradually 🙂

My dumb mistake

(Update 02-19-2021)

spring.io Testing the Web Layer

Mockito Example with Best Practices

JUnit and Mockito : Best Practices, Do’s and Don’ts

(Original) Test Driven Development (TDD) is getting popular these days. I had opportunity to being exposed it recently. I am not new to unit test. In the software company I worked for 8 years, we have regression test suites that runs automatically (at least daily), and we update the test suites as we find edge cases from customer bug reports, or in our development. That was about 8 years ago. Since the switch into Java land (2010), I started using JUnit and create/run the unit tests. One thing I was exposed to recently is Mocking in unit test, and TDD. Both takes a little time, and I am not fully bought into TDD yet. But I did learned something interesting on both topics lately, and like to share.

1) TDD
One of my coworker is very experienced and in-grained in this, as we are doing pair programming, I learned this a bit. An interesting back and forth as I was making changes to a method.

Coworker: “Do you have a test case?”
Me: test case for what?
Coworker: for the change?
Me: do we need this? …

But eventually we wrote the case, magically the web app also worked as soon as we passed the unit test. But overall I still have some reservation to do this, as I am not good at mocking e.g. Mockito, or writing test, and I think there is some cases pair programming can get the code right without go heavy in unit test.

Some links for mockito and spring test

Stubbing and Mocking with Mockito and JUnit

https://www.vogella.com/tutorials/Mockito/article.html
https://stackoverflow.com/questions/39486521/how-do-i-mock-a-rest-template-exchange
https://www.baeldung.com/spring-mock-rest-template
https://stackoverflow.com/questions/11969609/junit-mockito-when-thenreturn-throws-nullpointerexception/18060451
https://javacodehouse.com/blog/mockito-tutorial/

2) Unit test (auto test suites)
I heard from my coworker recently that test suites should not use the implementation data source (database). I thought the main reason is the heavy weight/use from database resources point of view. But there is more, today I found if auto test consistently changes things on dev database, it’s really hard to find out the root cause, and cause confusion. Initially we thought the problem was caused by batch job, or the web app, spent a lot time trying to figure out, both are not the cause. And luckily, at the end we were able to find out the real cause.

This is the common saying I heard a lot when I started worked for a software company on development. I can list some of the pros and cons of fix it.

Pros
Architecture chaos: if not fixing it, basically as the software ages, per the “broken windows” theory, people would just throw in changes to get things done, without carefully thinking about the architecture, dependencies. And this leads to the related problem below.

Code hard to maintain: it will become harder and harder to fix bugs, or add new features with the code in a messy state.

Cons
Introduce new bugs by accident. Or the fix making the software worse. While it’s unlikely, it’s still possible. Not carefully planned fix could introduce bugs, and make the software worse. I have done my share of that too 🙁

Refactor
If we were to work on the clean up, refactor the code, as a minimum we should have the regression test suites. Or in ideal world, we would have automated unit tests, which could help both speed up development, and give another level of confidence for the code change.