Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

ehance testability of clients

Đang mở
  • Có gì không ổn?
#105 2 bình luận 0 reaction 1 người được giao Xem trên GitHub

@gresrun đang làm issue này rồi.

Từ ngày 26/3/2016.

Đánh giá

Issue này chưa được đánh giá.

Mô tả

Discussion

cool library with some interesting ideas.

Ideally, I was trying to create a simple wrapper to hide jesque(and simulate jesque) from a testability perspective. Unfortunately, the design seems to be preventing that or I am missing a method I could use? Perhaps you might know?

I was trying to create a singleton like so

public class ResqueWrapper {

public void addQueueListener(ResqueListener l, Collection<String> queueNames) {
  //VERY VERY little code that I can only test in staging
}

public void remoteQueueListener(ResqueListener l) {
}

}

As I got into implementing this, I found out jesque is doing some reflection stuff that I would like to avoid especialy since it is on my business logic and I prefer to have all business logic stateless and created via guice. I really just want jesque to call

resqueListener.processItemsInQueue(String fromQueue, Items items)
resqueListener.failed(fromQueue, Throwable t)

where Items has an ack or nack. Then I can fully simulate my system. Unfortunately, jesque is making it really hard to wrap my system in a 'large' system type test where I swap out guice remote endpoints(so it's all single threaded and doesn't talk remotely at all during the test). This enables us to test talking to S3 failures after getting a resque item and make sure the system does what it is supposed to on an S3 failure or an mysql failure, etc. etc.

Is there any way to do this?

For one thing, the reflection to create a job class is what is hurting me. Reflection to create a data object to pass into a generic resque listener would have been ok like ResqueListener

Ideally, the api should only be passing data rather than fiddling with my business logic such that my test can easily do the same. It just creates a situation in which the test can simulate 99% of the code rather than 70% of the code which is what we have right now.

It's hard to explain this concept, but basically our tests on other projects do this

  1. feed in data through to the listener(test has a reference to the listener as it mocks the ResqueWrapper to be able to grab the listeners that were added)
  2. from there it is 100% production code until the remote endpoint
  3. at the remote endpoint, our test throws an exception
  4. then we verify a call to mysql results in recording that exception as well(which again is a mocked endpoint).

thanks,
Dean

Ngôn ngữ chính
Java
Star
629
Fork
133
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của gresrun/jesque

Tất cả issue của gresrun/jesque

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.