stlplace

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.