Rigorous tests makes them comfortable

 

The more investment in a big project, the higher the expectations.

With high expectations comes high pressure on the development team.

How can we reduce the pressure?

How can we find peace of mind?

There is no way but through extensive testing.

Achieving 100% test coverage can bring peace of mind and confidence.

Of course even 100% coverage does not catch every case, so it is not a guarantee.

But less than 50-60% feels insecure.

Increasing coverage is tedious and painful work.

Especially on code you didn't write.

If achieving 100% can bring the whole team peace, it's worth doing.

This is the era of CI/CD.

100% coverage should be the norm.

Developers, let's mature.

Testing is not menial or low level.

In fact it is advanced and essential work.

투자를 많이 한 큰 프로젝트일수록 기대가 높다.

기대가 높은 만큼 그걸 개발하는 개발팀은 부담감이 높다.

부담감을 줄이는 방법은 뭘까?

마음의 평화를 주는 방법은 뭘까?

테스트를 많이 하는 방법밖에 없다.

테스트 커버리지 100%를 달성하면 마음의 평화와 자신감을 줄 수 있을 것이다.

물론 테스트 커버리지 100%라도 해도 모든 테스트 케이스를 커버하진 않을 것이므로, 그것이 100% 안정성을 보장하진 않는다.

하지만, 50%~60% 정도의 테스트 커버리지 상태면 불안할 수 밖에 없다.

테스트 커버리지를 높이는 과정은 지루하고 고통스럽다.

특히 그것이 자신이 만든 코드가 아니면 더욱 그럴 것이다.

팀 전체를 위해서 테스트 커버리지 100% 달성이 모두에게 평화를 줄 수 있다면 기꺼이 할 수 있다. 

CI/CD 가 유행하는 시대이다.

100% 테스트 커버리지를 유지하는 것이 당연한 시대이다.

개발자들이여, 더 성숙해지자.

테스트 개발은 한직도 아니고 낮은 수준의 일이 아니다. 

사실은 그 반대로 매우 고급 기술이고 중요한 업무이다.

Strength In Erlang

When working on projects not using Erlang, the toughest thing is releasing without complete unit tests, integration tests, and stress tests for all APIs.

Erlang projects also need those tests before release.

But a huge plus is updating without service interruption after issues arise. Especially great for socket services needing to maintain session context!

So despite lower computation speed than C++ servers, Erlang can't be beat. And it's not drastically slower - for I/O heavy work differences are small. With excellent multi-core support, Erlang can even outperform servers lacking it.

A paper comparing Go, Erlang, and Akka is a must-read!

Recommendations:

• Use Erlang for socket services maintaining session context.
• For HTTP REST services Erlang isn't critical.
• Despite advantages, Erlang lacks explosive popularity due to difficult syntax and small community. Elixir helps but isn't sufficient yet and feels awkward to existing Erlang devs. Devs new or scared of Erlang can use Elixir.

Coverage Tests, Work load tests Before Release

실전에서 Erlang으로 서버를 만들지 않은 프로젝트를 접했을때,
가장 난감한 점은
"모든 API에 대한 유닛테스트와 전체 서비스에 대한 통합 테스트,그리고 스트레스 테스트를 반드시 통과해야 하지 않고서는 서비스 오픈이 겁난다"이다.

Erlang으로 했을 때에도, 유닛테스트,통합 테스트,스트레스 테스트를 하지 않는 것은 아니다.

Hot Code Reloading

그러나, 오픈후에 문제 상황 발생시에, 곧바로 원인을 파악하고, 서비스를 중단하지 않으면서 업데이트를 할 수 있다는 점은 엄청난 장점이 아닐 수 없다.
Session Context를 유지해야 하는 Socket 기반 서비스에서는 특히 그 장점이 빛이 난다.


Performance

따라서, C++ 서버(Native Binary를 지원하는)에 비해서 떨어지는 Computation 성능에도 Erlang을 선택하지 않을 수 없다.
그렇다고, 특별히 현저하게 성능이 떨어지는 것도 아니다. I/O bound job이 많은 경우에는 차이가 별로 나지 않을 뿐더러, Multi Core Support를 매우 훌륭하게 지원하기 때문에, Multi Core Support를 제대로 지원하지 않은 서버에 비하여 오히려 성능이 매우 우수하다.

Go , Erlang , Akka 를 비교한 논문이 있다. 꼭 읽어보길 바란다.

http://www.dcs.gla.ac.uk/~trinder/papers/sac-18.pdf

Recommendation

* Session Context를 유지해야 하는 Socket 기반 서비스에는 Erlang으로 구현한다.

* 그렇지 않은 http REST 기반 서비스는 Erlang이 아니어도 상관없을 듯 하다.

* 이러한 장점에도 불구하고, Erlang이 폭발적인 인기를 끌고 있지 못하는 이유는, 어려운 문법과 작은 커뮤니티일 것이다. Elixir가 그 단점을 커버하기 시작했지만, 충분하지 않고, 기존의 Erlang 개발자에게는 오히려 불편하다. Ruby 경험자나 Erlang을 처음 접하기 겁나는 개발자는 Elixir로 구현해도 될 듯하다.