I'm currently extending Degraph to check for violation of dependency rules.
So far I have created matchers for ScalaTest, since this is my favorite test library for the JVM. But many others prefer or have to use other libraries. So I'd like to provide matchers (or whatever is the appropriate equivalent) for those as well.
On the other hand I'm lazy so I don't want to provide a matcher for every conceivable library.
So the question is:
Is there some kind of matcher library that can be used in all (or the most / many) test libraries? Or maybe a wrapper that converts Hamcrest matchers to matchers for all the other libs?
The libraries I would like to support (in that order of importance):
JUnit
ScalaTest
most popular testing library for Groovy
most popular testing library for Clojure
Specs2
TestNG
Every unit testing framework I've seen will fail a test that throws an exception.
Hamcrest's assertThat(T value, Matcher<T> matcher) will throw an AssertionError if matcher.matches(value) returns false.
Therefore, Hamcrest should work out-of-the-box with most testing frameworks. For other libraries, such as for building mock objects, you'll need to either use Hamcrest's Matcher objects natively or write an integration layer. One way would be to create a method to decorate any matcher, for example*,
ArgumentMatcher<T> decorate(final Matcher<T> matcher) {
return new ArgumentMatcher() {
public boolean <T> accepts(T value) {
return matcher.matches(value);
}
}
}
* This is a contrived example using a theoretical Mocking API.
Related
In book 'Kotlin in Action', it says Kotlin DSL structure is most commonly created through chained method calls. Also, a typical library consists of many methods and no context is maintained btw one call and the next.
I'm confused of which side sequence is close to. Before I read this, I've thought sequence is just API of library, but it really fits with feature of DSL.
I'm not 100% sure this answers your question, but I would not think of Sequence pipelines as a "DSL" per se, in particular because it is quite general, which is the opposite of "domain-specific" - the heart of the definition of a DSL.
If you build your own builder API based on chained method calls for a specific domain, you could consider that as a DSL, but I would say Kotlin DSLs are mostly made of nested lambdas with declarative property assignments, rather than chained method calls.
This is because lambdas in Kotlin give the illusion of blocks and structure more than actual functions and function calls, which is why nested structures like this look like their own "language" (the L of DSL). Chained method calls don't look like another "language" - they just look like function calls, but of course that's my subjective take.
For example, here is a Gradle build script using the Gradle Kotlin DSL:
plugins {
`java-library`
}
dependencies {
api("junit:junit:4.13")
implementation("junit:junit:4.13")
testImplementation("junit:junit:4.13")
}
java {
sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11
}
It does look like its own language, you don't immediately think of Kotlin when reading such code.
I am very new to Kotlin development and I came across custom annotation classes in the documentation.
Is there a way for me to use an annotation on a function as a way to pre-populate some variables, or to run a decorator function before running the annotated function?
Something like:
class TestClass {
#Friendly("Hello World")
private fun testFun() {
greet()
//does something else
}
}
with an annotation class like
#Target(AnnotationTarget.FUNCTION)
#Retention(AnnotationRetention.BINARY)
annotation class Friendly(val message: String) {
fun greet() {
println(message)
}
}
I know this isn't valid Kotlin code, but I can't find any examples on how to actually use values from annotations without using reflection (if it's even possible)
Please let me know if I can do something like this, and more usefully, a better resource on annotation classes for Kotlin?
To make use of your custom annotations, you need to either create your own annotation processor (and use kapt Kotlin compiler plugin) to generate some new sources (but not modify existing!) at compile time, or use #Retention(AnnotationRetention.RUNTIME) meta-annotation (which is default in Kotlin), so that they could be accessed via reflection in runtime.
#Retention(AnnotationRetention.BINARY) meta-annotation you're using is equivalent of #Retention(RetentionPolicy.CLASS) in java, which is mostly useless (see https://stackoverflow.com/a/5971247/13968673).
What you're trying to do with annotations (call some additional code before/after method execution) reminds me aspect-oriented programming. Take a look at Spring AOP and AspectJ frameworks, following this paradigm, and their approach for annotations processing. TL;DR: Spring AOP is processing annotations in runtime, generating proxy-classes with respectful code, while AspectJ is using its own compiler (even not an annotation processor, cause it also introduces its own syntactic extension for java language), and can generate respectful bytecode at compile-time. They both are originally java-oriented, but with some configurational pain could be used with Kotlin too.
I have a method that I need to instrument to call New Relic: setup a segment, run the business logic and end the segment. Is there a way to do it in Kotlin (as in Spring AOP)?
fun saveCustomer() {
val segment = NewRelic.getAgent().transaction.startSegment("save customer")
// business logic here
segment.end()
}
I experimented isolating newRelic dependency and can now reuse it across my whole app:
fun saveCustomer() {
newRelic.executeWithSegment { // this starts/ends the segment and calls the function block
// business logic here
}
}
However, this makes unit testing of saveCustomer harder, because after mocking newRelic.executeWithSegment (which I must; otherwise New Relic is contacted in the tests), the code block (business logic) is not executed anymore - so the test fails.
Is there a way to fulfill those requirements? (Perhaps with an annotation or using Kotlin delegation pattern or even some lightweight library; not sure.)
You can use AspectJ.
It is independent of Spring, more powerful and more efficient (no proxies) than Spring AOP.
It should work with any JVM language, although I never tried with Kotlin as a target for my aspects.
If you do compile-time weaving, the AspectJ runtime is the only dependency you need. Its size is 120K.
For load-time weaving you need the AspectJ weaving agent instead. Its size is 1.9M.
I’m looking for a multi-platform alternative to input streams. My concrete task is to fetch an encrypted file from a remote server via https and decrypt it on demand.
In Java land I would an implement InputStream which proxies the reads to the input stream from the https library. How can I do the same in kotlin targeting multiple platforms.
I see ktor returns an ByteReadChannel, but I don’t know which functions.
I’m lost and don’t know where to start. Thanks for your help in advance.
If the framework you are using does not provide you with a full-fledged InputStream implementation, the only chance left is to write your own. Much like what the ktor developers did: ByteReadChannel is just an abstraction of "reading bytes from a channel".
This abstraction lives in the common part and allows to write application and business logic around it.
The key to make this work in the context of a Kotlin Multiplatform project is, the actual implementation needs to be provided in the platform specific parts. The JVM specific code of the ktor project actually has an implementation that uses InputStream: InputStream.toByteReadChannel.
You certainly don't have to do it like your example from the ktor project and model everything down from byte channels up to file representations. If you want to leverage Kotlin framework classes, Sequences might be handy. This could look something like this:
// in common
interface FileFetcher {
fun fetch(): Sequence<Byte>
}
expect fun fileFetcher(source: String): FileFetcher
// in jvm
class JvmFileFetcher(val input: java.io.InputStream): FileFetcher {
override fun fetch(): Sequence<Byte> = input.readBytes().asSequence()
}
actual fun fileFetcher(source: String): FileFetcher {
val input = java.net.URL(source).openStream()
return JvmFileFetcher(input)
}
You would define an interface FileFetcher along with a factory function fileFetcher in the common part. By using the expect keyword on the fileFetcher function you need to provide platform-specific implementations for all target platforms you define. Use the FileFetcher interface in the common part to implement your logic (decrypting file contents etc.). See the documentation for Sequence for how to work with it.
Then implement the factory function for all platforms and use the actual keyword on them. You will then need to write platform-specific implementations of FileFetcher. My example shows how a JVM version of the FileFetcher interface.
The example is of course very basic and you probably would not want to do it exactly like this (at least some buffering would be needed, I guess). Also, within the JVM part you could also leverage your favorite networking/HTTP library easily.
I am not sure if what i am doing is actually the "correct" way of doing unit tests with DI. Right now i ask my ViewModelLocator to actually create all the instances i need, and just get the instance i need to test, which makes it very simple to test a single instance because lets asume that Receipt needs a Reseller object to be created, reseller needs a User object to be created, user need some other object to be created, which creates a chain of objects to create just to test one single instance.
With di usally interfaces will get mocked and parsed to the object which you would like to create, but how about simple Entities/ViewModels?
Whats the best practice to do unit testing with DI involved?
public class JournalTest
{
private ReceiptViewModel receipt;
private ViewModelLocator locator;
[SetUp]
public void SetUp()
{
locator = new ViewModelLocator();
receipt = SimpleIoc.Default.GetInstance<ReceiptViewModel>();
}
[TearDown]
[Test]
public void CheckAndCreateNewJournal_Should_Always_Create_New_Journal()
{
receipt.Sale.Journal = null;
receipt.Sale.CheckAndCreateNewJournal();
Assert.NotNull(receipt.Sale.Journal);
}
}
First, you aren't using Dependency Injection in your code. What you have there is called Service Locator (Service Locators create a tight coupling to the IoC/Service Locator and makes it hard to test).
And yes, it's bad (both Service Locator and Dependency Injection), because it means: You are not doing a UnitTest, you are doing an integration Test.
In your case the ReceiptViewModel will not be tested alone, but your test also tests the dependencies of ReceiptViewModel (i.e. Repository, Services injected etc.). This is called an integration test.
A UnitTest has to test only the class in question and no dependencies. You can achieve this either by stubs (dummy implementation of your dependencies, assuming you have used interfaces as dependencies) or using mocks (with a Mock framework like Moq).
Which is easier/better as you don't have to implement the whole class, but just have to setup mocks for the methods you know that will be required for your test case.
As an additional note, entities you'll got to create yourself. Depending on your UnitTest framework, there may be data driven tests (via Attributes on the test method) or you just create them in code, or if you have models/entities used in many classes, create a helper method for it.
View Models shouldn't be injected into constructor (at least avoided), as it couples them tightly
Units tests should run quickly and should be deterministic. That means you have to mock/stub everything that brokes these two rules.
The best way to mock/stub dependancies is to inject them. In the production, classes are assembled by DI framework, but in unit tests you should assemble them manually and inject mocks where needed.
There is also a classic unit test approach where you stub/mock every dependency of your class, but it's useless since you don't gain anything by that.
Martin Fowler wrote great article about that: link
You should also read Growing Object-oriented software: Guided by tests. Ton of useful knowledge.