tag:blogger.com,1999:blog-1980461574999551012.post4044949875227695807..comments2023-08-31T06:48:52.612-04:00Comments on Kobrix Software, Official Blog: On TestingUnknownnoreply@blogger.comBlogger2125tag:blogger.com,1999:blog-1980461574999551012.post-29315579962594800902012-09-29T22:19:17.029-04:002012-09-29T22:19:17.029-04:00The pros and cons of mutable state is a debate on ...The pros and cons of mutable state is a debate on its own. But I don't see how it has to do with testing? If you test a program as a black box, how does it matter if it's written with mutable state or in a functional style? What's more important is how the program's observable behavior is specified. You are probably having trouble because you think of the behavior in terms of the implementation so you conceive starting from the mutable state. And HGDB in particular is a database, so it's all about read and write.Borislav Iordanovhttps://www.blogger.com/profile/01780885752802085533noreply@blogger.comtag:blogger.com,1999:blog-1980461574999551012.post-54960200586930090952012-09-25T13:37:59.136-04:002012-09-25T13:37:59.136-04:00I can only talk on my limited perspective of an am...I can only talk on my limited perspective of an amateur programmer, but I have found that it is mutable stateful code that renders testing difficult. I was doing tests of the redis-port, using the automated testing framework scalacheck, an adapted Haskel tool. Testing was really easy for code that was composed of referentially transparent functions and immutable data. As soon as I got to classes that depended on mutable state, it got really complicated to test.<br />It seems to me that HyperGraphDB's complexity when debugging and testing is because generally it is written in a imperative & mutable manner. One thing that really disturbed me more than once, is the dependency of the current JavaTypeMapper on Beans, which requires a null constructor, getters and setters. This is problematic if you want to write immutable classes which normally don't have any public setters. It also hurts compatibility with functional JVM languages such as scala, at least "idiomatic scala".<br />I still don't know well myself how to avoid mutability for non-trivial projects with many interdependent compontents, so I cannot really suggest something concrete (yet), but I'd advocate to consider reducing dependency on mutable state.greenhornhttps://www.blogger.com/profile/18160707499479654366noreply@blogger.com