单元测试java项目中所有类的可序列化 [英] Unit Testing serializability for all classes in java project

问题描述

我的java项目中有数千个类。其中一些实现了可序列化的接口。现在这是一个问题。有人可以进入一个类，添加既不是瞬态也不可序列化的新变量。代码编译正常但是进程会在运行时爆炸。

I've thousands of classes in our java project. Some of them implements serializable interface. Now here's a problem. It's possible someone can go in a class, add new variable that is neither transient nor serializable. Code compiles fine however process would blow up at runtime.

为了说明这个

class Foo implements Serializable {  .... // all good }

class Foo implements Serializable 
{  
    // OOps, executorService is not serializable.  It's not declared as transient either 

    private ExecutorService executorService = ..
}

我正在考虑编写一个单元测试，该测试将通过所有类并确保真正的可串行化。我已经阅读了一些关于连续特定对象的讨论。我理解这个过程，但它需要

I'm thinking about writing a unit test that would go thru all classes and ensure "true serializability". I've read some discussions about serialing specific objects. i understand that process but it requires

1）创建一个对象。

2）序列化然后

3）反序列化。

1) creating an object.
2) serializing and then
3) deserializing.

是否有更有效和实用的方法。也许用反射。通过所有类，如果类具有可序列化，那么所有属性必须是可序列化的或具有临时关键字..

Is there more efficient and practical approach. perhaps to use reflection. Go thru all classes, if class has serializable then all attributes must be serializable or have transient keyword..

思考？

推荐答案

1）创建一个对象。 2）序列化然后3）反序列化。

1) creating an object. 2) serializing and then 3) deserializing.

此列表不完整;你还需要初始化。考虑一下这个例子：

This list is not complete; you also need initialization. Consider the example:

class CanBeSerialized implements Serializable {
    private String a; // serializable
    private Thread t; // not serializable
}

class CannotBeSerialized implements Serializable {
    private String a;                // serializable
    private Thread t = new Thread(); // not serializable
}

您可以序列化和反序列化第一个，但是你' ll在第二个上获得 NotSerializableException 。为了进一步复杂化，如果使用接口，你永远无法判断一个类是否会通过序列化，因为它是流接口的类的具体对象：

You can serialize and deserialize the first one, but you'll get NotSerializableException on the second. To complicate the matter further, if interfaces are used, you can never tell if a class will pass serialization, as it's the concrete object of the class behind this interface that will be streamed:

class PerhapsCanBeSerializedButYouNeverKnow implements Serializable {
    private Runnable r; // interface type - who knows?
}

前提是您可以为所有课程和课程保证以下内容由你的班级使用来测试：

Provided that you could guarantee the following for all your classes and classes used by your classes to be tested:

• 默认构造函数存在，


• 否字段中的接口类型，

然后您可以通过反射自动创建和初始化它们，然后测试序列化。但这是一个非常艰难的条件，不是吗？否则，正确的初始化归结为手动工作。

then you could automatically create and initialize them by reflection, and then test serialization. But that is a really hard condition, isn't it? Otherwise, proper initialization is down to manual work.

您可以以不同的方式使用反射：迭代 Class 要检查的对象，为它们获取 Field [] ，并验证它们是否是瞬态的（ Field.getModifiers（））或者是否直接实现 Serializable （ Field.getType（）。getInterfaces（））或间接（通过超级接口或类）。另外，请考虑要检查的深度，具体取决于序列化机制的工作深度。

You could use reflection in a different way: iterating through a list of Class objects you want to check, getting the Field[] for them, and verifying if they're transient (Field.getModifiers()) or if they implement Serializable directly (Field.getType().getInterfaces()) or indirectly (via a super interface or class). Also, consider how deep you want to check, depending on how deep your serialization mechanism works.

正如Ryan所指出的那样，如果代码是正确的话，这种静态序列化检查会失败邪恶：

As Ryan pointed out correctly, this static serialization check would fail if the code was evil enough:

class SeeminglySerializable implements Serializable {
    // ...
        private void writeObject/readObject() {
             throw new NotSerializableException();
        }
}

或者只是 readObject（ ）/ writeObject（）实施得很糟糕。要测试这类问题，你需要实际测试序列化过程，而不是它背后的代码。

or just if readObject()/writeObject() were badly implemented. To test against this kind of problems, you need to actually test the serialization process, not the code behind it.

这篇关于单元测试java项目中所有类的可序列化的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！