Làm thế nào để kiểm tra đơn vị ClassLoader tùy chỉnh?


8

Vì một số lý do, tôi cần có con trước ClassLoader. Điều ClassLoaderđó không tồn tại trong JDK, vì vậy tôi đang viết nó. Vì đây là thành phần chính trong trường hợp sử dụng của tôi, tôi muốn nó được thử nghiệm nhiều. Để đảm bảo nó không bị thay đổi mà không phá vỡ hành vi, tôi muốn cực kỳ kỹ lưỡng và tự động kiểm tra tất cả những gì có thể kiểm tra được.

Vì vậy, làm thế nào tôi có thể kiểm tra nó? Làm thế nào tôi nên làm bài kiểm tra đơn vị cơ bản của tôi? Tôi bị kẹt khi bắt đầu từ đâu (đặc biệt là vì có ít nhất một supercuộc gọi trong mỗi phương thức) và tôi đang tìm một số hướng dẫn để bắt đầu.

Ý tưởng chính của tôi là như sau. Có điều gì sai với nó?

/src/main/resources/parent.jar
                    child.jar

Các tập tin parent.jarcó chứa một lớp com.example.Examplelà một Suppliertrả về cơ bản "parent". Các tập tin child.jarcó chứa một lớp com.example.Examplelà một Suppliertrả về cơ bản "child".

Tôi sẽ tạo một tiêu chuẩn URLClassLoadercho parent.jarvà tôi sẽ sử dụng tùy chỉnh của mình ClassLoaderđể tải child.jar. Sau đó, tôi sẽ tải lớp com.example.Examplevà kiểm tra xem nó thực sự trở lại "child"thay vì "parent".

Các trường hợp kiểm tra phức tạp hơn được nghĩ đến, nhưng tôi chỉ cần một xác nhận để bắt đầu: điều này có đủ cho bài kiểm tra cơ bản không? Đây thực sự là những gì tôi nên kiểm tra trong bài kiểm tra đơn vị của tôi? Nếu không, là gì?


Tôi khá chắc chắn rằng mã không cần thiết cho việc này, nhưng trong trường hợp bạn tò mò hoặc bất cứ điều gì, đây là nó.

import java.io.*;
import java.net.*;
import java.util.*;

class ChildFirstClassLoader extends URLClassLoader {

  ChildFirstClassLoader(ClassLoader parent) {
    super(new URL[0], parent);
  }

  @Override
  // Make this method available in this package.
  protected void addURL(URL url) {
    super.addURL(url);
  }

  @Override
  protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    synchronized (getClassLoadingLock(name)) {
      Class<?> c = findLoadedClass(name);
      if (c == null) {
        try {
          c = findClass(name);
        } catch (ClassNotFoundException ignore) {
          c = super.loadClass(name, resolve);
        }
      }
      if (resolve) {
        resolveClass(c);
      }
      return c;
    }
  }

  @Override
  public URL getResource(String name) {
    URL url = findResource(name);
    if (url == null) {
      url = super.getResource(name);
    }
    return url;
  }

  @Override
  public Enumeration<URL> getResources(String name) throws IOException {
    List<URL> urls = new ArrayList<>();
    urls.addAll(Collections.list(findResources(name)));
    urls.addAll(Collections.list(super.getResources(name)));
    return Collections.enumeration(urls);
  }
}

1
Vâng, bạn đã có ý tưởng đúng. Bạn cần xác thực rằng (1) cho bất kỳ lớp nào có tên "X" mà bạn giải quyết X bằng trình nạp lớp thích hợp và (2) rằng trình nạp lớp sẽ ủy thác mọi yêu cầu mà nó không thể thực hiện đầy đủ.
kdgregory

(và câu hỏi này có lẽ phù hợp với SO hơn PSE)
kdgregory

1
Trên SO, tôi sợ câu hỏi này sẽ bị đóng vì lạc đề vì đây là cách hỏi ý kiến về thử nghiệm thích hợp.
Olivier Grégoire

Vâng, buồn là đôi khi chúng ta sợ làm cho câu hỏi.
djangofan

Câu trả lời:


2

Vì vậy, làm thế nào tôi có thể kiểm tra nó? Làm thế nào tôi nên làm bài kiểm tra đơn vị cơ bản của tôi? Tôi bị kẹt khi bắt đầu từ đâu (đặc biệt là vì có ít nhất một siêu cuộc gọi trong mỗi phương thức) và tôi đang tìm một số hướng dẫn để bắt đầu.

Cấp cho tôi không biết nhiều về ClassLoaders hoặc Java cho vấn đề đó, nhưng tôi sẽ gặp khó khăn khi kiểm tra đơn vị này. Một trong những lý do là, như bạn nêu, lớp của bạn kế thừa từ URLClassLoader. Ngay cả khi chúng ta có thể chế nhạo siêu lớp bằng cách nào đó, tôi sẽ không tin tưởng nhiều vào các bài kiểm tra xác minh rằng việc triển khai của tôi thực hiện những gì dự định làm.

Vì vậy, với giá trị của nó, tôi sẽ dựa vào việc viết một bài kiểm tra tích hợp hơn ở đây: Có thể có một vài thư mục "lịch thi đấu" có chứa các ví dụ như bài bạn đã trình bày:

  • Đồ đạc
    • Có thể tải thành công
      • cha mẹ
      • child.jar
    • Th NémAnErrorOnLoad
      • justparent.jar

Điều đó sẽ dẫn đến việc tôi viết một bài kiểm tra cho từng trường hợp đó và "sử dụng" các lớp cha / con theo cách rất đơn giản chỉ để xác minh nó đã tải hoặc không tải như tôi mong đợi.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.