Tuesday, May 7, 2013

Creating a REST web service using webtoolkit (aka witty)

I previously introduced witty as a powerful web framework for C++ developers, mostly those one that don't want to re-invent the wheel and become productive.  Witty uses a resource-based approach to register services that listen on specific paths (resource paths), these resources are registered on the witty server first and the server is started later.

So the steps of an standalone witty w/ custom resource server:

  1. create a server
  2. register a custom resource on a desired path
  3. start the server, hence its resources
  4. wait for server shutdown signal
  5. stop the server

Here is the snippet of the main.cpp,  ignore all log-related plumbing:


#include <Wt/WServer>
#include <iostream>
#include "MyResource.h"
#include "log.h"

using namespace std;
using namespace Wt;

int main(int argc, char **argv) {
 WLogger logger;
 configLogger(logger);
 try {
  WServer server(argv[0], "");
  try {
   server.setServerConfiguration(argc, argv);
   MyResource dr;
   server.addResource(&dr, "/resource");
   info(logger, "Starting resource server.");
   if (server.start()) {
    WServer::waitForShutdown();
    server.stop();
   } else {
    fatal(logger, "Fatal error starting resource server.");
    return 1;
   }
   return 0;
  } catch (std::exception& e) {
   fatal(logger, "Fatal error starting resource server.", e.what());
   return 1;
  }
 } catch (WServer::Exception& e) {
  fatal(logger, "Fatal error creating WServer.", e.what());
  return 1;
 } catch (exception& e) {
  fatal(logger, "Fatal error occurred.", e.what());
  return 1;
 }
}

You may notice the creation and registration of MyResource, this is place where you provide the service implementation, specifically on the handleRequest() method, take a look at MyResource.h:

#ifndef MYRESOURCE_H_
#define MYRESOURCE_H_

#include <Wt/WResource>

using namespace Wt;
using namespace Wt::Http;

class MyResource: public WResource {
 public:
  MyResource();
  virtual ~MyResource();
 protected:
  virtual void handleRequest(const Request &request, Response &response);
};

#endif /* MYPRESOURCE_H_ */

The implemantation is very trivial, it's just an echo of the request content also including some extra data like content type, content length and request method: GET, POST, etc. Enjoy MyResource.cpp:
#include <iostream>
#include <Wt/Http/Response>
#include "MyResource.h"

using namespace std;
using namespace Wt::Http;

MyResource::MyResource() {
}

MyResource::~MyResource() {
}

void MyResource::handleRequest(const Request& request, Response& response) {
 string method = request.method();
 string contentType = request.contentType();
 int contentLength = request.contentLength();
 char* buffer = new char[contentLength + 1];
 request.in().read(buffer, contentLength);
 buffer[contentLength] = 0;
 response.setMimeType("application/xml");
 ostream& out = response.out();
 out << "<?xml version='1.0' encoding='utf-8' ?>" << endl;
 out << "<reply>" << endl;
 out << "<method>" << method << "</method>" << endl; 
 out << "<contentType>" << contentType << "</contentType>" << endl;
 out << "<contentLenght>" << contentLength << "</contentLenght>" << endl;
 out << "<body>" << buffer << "</body>" << endl;
 out << "</reply>";
 delete[] buffer;
}


The reamining stuff is just plumbing as I said before, here you got log.h:
#ifndef LOG_H_
#define LOG_H_

#include <Wt/WLogger>

using namespace std;
using namespace Wt;

void info(WLogger& logger, const string& message);
void fatal(WLogger& logger, const string& message, const char* what);
void fatal(WLogger& logger, const string& message);
void configLogger(WLogger& logger);

#endif /* LOG_H_ */

And log.cpp:
#include "log.h"
#include <iostream>

void info(WLogger& logger, const string& message) {
 WLogEntry entry = logger.entry("info");
 entry << WLogger::timestamp << WLogger::sep << WLogger::sep << '[' << "info"
   << ']' << WLogger::sep << message;
}
void fatal(WLogger& logger, const string& message, const char* what) {
 WLogEntry entry = logger.entry("fatal");
 entry << WLogger::timestamp << WLogger::sep << WLogger::sep << '['
  << "fatal" << ']' << WLogger::sep << message << what;
}

void fatal(WLogger& logger, const string& message) {
 fatal(logger, message, "");
}

void configLogger(WLogger& logger) {
 logger.addField("datetime", false);
 logger.addField("type", false);
 logger.addField("message", true);
 logger.setFile("/var/log/resource.log");
}

Now compile an run the server, here in this case using standalone server mode instead of fast cgi mode, but also works w/ fast cgi variant:
$ g++ log.cpp MyResource.cpp main.cpp -lwthttp -oresource

Run the server:
$ ./resource --http-address 0.0.0.0 --http-port 80 --docroot=.
INFO: Opened log file (/var/log/resource.log).
[2013-May-07 19:52:11.046985] 9658 - [info] "config: reading Wt config file: /etc/wt/wt_config.xml (location = './resource')"
[2013-May-07 19:52:11.047757] 9658 - [info] "WServer/wthttp: initializing built-in wthttpd"
[2013-May-07 19:52:11.048027] 9658 - [info] "wthttp: started server: http://0.0.0.0:80"

Finally test the service using a simple call:
$ curl -X POST -H "Content-Type: application/xml" -d"<payload>PAYLOAD GOES HERE!</payload>" http://localhost/resource
<?xml version='1.0' encoding='utf-8' ?>
<reply>
<method>POST</method>
<contentType>application/xml</contentType>
<contentLenght>37</contentLenght>
<body><payload>PAYLOAD GOES HERE!</payload></body>
</reply>
Very simple as you can see!

Thursday, May 2, 2013

ImageMagick convert to raw RGB format in C++

This is a code snippet to convert from any supported ImageMagick format to raw RGB format, it's just an example on how to use the conversion features of ImageMagick libraries. The example was tested on both: Windows and Linux.

#include <Magick++.h>
#include <iostream>
#include <boost/filesystem.hpp>

using namespace std;
using namespace Magick;
using namespace boost::filesystem;

int main(int argc, char **argv) {
 Image img;
 string src_path;
 string tgt_path;
 Blob blob;
 FILE* tgt_file;

 InitializeMagick(*argv);

 // read image
 src_path = argv[1];
 if(exists(src_path)) {
  img.read(src_path);
  cout << "Detected format: " << img.format() << endl;

  // set raw RGBS output format & convert it into a Blob
  img.magick("RGB");
  img.write(&blob);

  // dump blob to disk
  tgt_path = src_path + ".RGB.raw";
  tgt_file = fopen(tgt_path.c_str(), "wb");
  fwrite(blob.data(), blob.length(), 1, tgt_file);
  fclose(tgt_file);
  cout << "Converted to raw RGB: " << tgt_path << endl;
  exit(0);
 } else {
  cout << "Could not load image, file not found " << src_path << endl;
  exit(1);
 }
}

Recording dialog-based interactive user input using expect on Linux

This is a how to successfully combine the shell script dialog tool with expect in order to record all user interactions and repeat them later. You can apply expect to record almost anything on a terminal, I applied it on a very complex dialog-based installation wizard with 100% success. There's nothing special here, nor a magic spell. The solution is pretty straightforward: start recording, launch dialogs + interact, stop record and finally replay it on a hit.

Show the example dialogs below:

#!/bin/bash
#
# dlgs.sh : all dialogs in one script, 1- a radio list, 2- a Yes/No dialog, 3-An input box


  
radiolist_result=$(dialog --stdout --clear --backtitle "Combining dialog w/ expect" \
   --radiolist "Select distro:" 10 40 3 1 "CentOS" off 2 "Ubuntu" on 3 "Debian" off)

dialog --stdout --clear --title "Simple question" --backtitle "Combining dialog w/ expect" \
  --yesno "Are you having fun?" 6 25 && yesno_result=Yes || yesno_result=No

inputbox_result=$(dialog --stdout --clear  --backtitle "Combining dialog w/ expect" \
  --inputbox "Enter your name:" 8 40)


I use CentOS 6 for this demo, but it seems to work on other distros:

$ yum -y install expect

Assign execution permissions to dlgs.sh:

$ chmod +x dlgs.sh

Start recording using autoexpect:

$ autoexpect
autoexpect started, file is script.exp

Call dlgs.sh and interact:

$ ./dlgs.sh
...
3
No
Eduardo Lago Aguilar
By pressing Ctrl+D end the session watch. Then verify the recording by calling the generated script:

$ ./script.exp
...
3
No
Eduardo Lago Aguilar

Very simple isn't? See more.

Thursday, February 21, 2013

Becoming unaware of the Dependency Injection Framework. Encouraging standarization

Intro

The previous post showed up how to combine Spring Framework, Mockito and Lombok in TDD fashion. But it's far from be the simplest and portable solution if such thing even exists. Let's try to make the whole example more unaware of the DI Framework, in this case Spring, but still use it for testing purposes.

Java 6 brought us several improvements, CDI among them. This refcardz is self-explanatory. IMO the main advantage of CDI is standardization, but CDI is pure specification, not an implementation, and its RI is Weld.

Results that Spring honors CDI since version 3.0, at least in Java Injection Standard (JSR-330). There is a bunch of posts and articles talking about the Spring support for CDI specifications, and which one is better to use. But this is not the goal of this post.

Goals

  • Become unaware of the DI Framework at design time
  • Support Spring at test time
  • Support Spring at runtime
  • Support others DI Framework at runtime

How to

  • By replacing @Autowired and using injection by name with @Resource
  • By naming beans using @Name and scanning packages for candidates instead of explicitly create the bean in application context configuration file.

Let's do it

As I said before, it's just an example. Real world scenarios are more complex, and you will end for sure combining many APIs from different sources.

  1. Use the example from the previous post.
  2. Include a couple of dependencies in your pom.xml.
  3. 
      javax.annotation
      jsr250-api
      1.0
    
    
      javax.inject
      javax.inject
      1
    
    
    JSR-250 provide us various standard annotations: @Resource, @PostConstruct, @PreDestroy , etc; these annotations are honored by Spring. In the other hand  with have JSR-333 (javax.inject) that give us @Inject, @Named, @Provider, @Qualifier, @Scope and @Singleton.
    Lets explain some of these annotations:
    • @Resource
      • Matching: First matches by name, then matches by type and filters by qualifiers if not name-based match gets found.
      • Applicable to: Fields, Classes and Methods.
      • Package: javax.annotation
    • @PostConstruct
      • Runs: After the bean construction and wiring
      • Applicable to: Methods.
      • Package: javax.annotation
    • @PreDestroy
      • Runs: Before the release of the bean
      • Applicable to: Methods.
      • Package: javax.annotation
    • @Inject
      • Matching:  First matches by type, filters by qualifiers, then matches be name.
      • Applicable to: Methods, Constructors and Fields.
      • Package: javax.inject
    • @Named
      • Description:  Its a qualifier that denotes a named bean. Annotated classes are considered for auto-detection on classpath scanning. It's similar to Spring's @Component
      • Applicable to: Classes and Fields.
      • Package: javax.inject
  4. Spring dependencies are now on test scope, since they are only required on test time. But in a real world scenario you will need a DI Framework, so don't forget to include Spring or Weld dependencies for production stage.
  5. 
      ...
     
      org.springframework
      spring-test
      ${spring.version}
      test
     
     
      org.springframework
      spring-beans
      ${spring.version}
      test
     
     
      org.springframework
      spring-context
      ${spring.version}
      test
     
      ...
    
    
  6. The test is an hybrid between Spring and more standard stuff, that is:
  7. package demos.sf.editor.test;
    
    import ... ;
    
    @RunWith(SpringJUnit4ClassRunner.class)
    @ContextConfiguration(locations = { "/test-applicationContext.xml" })
    @TestExecutionListeners({ DependencyInjectionTestExecutionListener.class,
      DirtiesContextTestExecutionListener.class })
    @DirtiesContext(classMode = ClassMode.AFTER_EACH_TEST_METHOD)
    public class EditorTest {
    
     @Resource
     private Editor editor;
    
     @Resource
     private SpellChecker spellChecker;
    
     @Test
     public void testPasteSuccess() {
      editor.paste("Hello everybody!");
    
      String expected = "Hello everybody!";
      String actual = editor.getText();
      assertEquals(expected, actual);
     }
    
     @Test
     public void testAddParagraphSpellIsChecked() {
      editor.paste("Hello everybody!");
      verify(spellChecker, only()).check("Hello everybody!");
     }
    }
    
  8. The SUT (Editor) is now DI Framework unaware:
  9. package demos.sf.editor.impl;
    
    import ...;
    
    @Named
    public class Editor {
    
     @Getter
     protected String text;
    
     @Resource
     private SpellChecker spellChecker;
    
     public void paste(String cut) {
      if (text == null) {
       text = "";
      }
      text += cut;
      spellChecker.check(cut);
     }
    }
    
  10. The application context configuration file for testing stage file is now simplified. Only package scanning is needed to create the SUT (Editor):
  11. 
    
     
    
     
      
     
    
    
    
    NOTE:Observe that some minor package relocation were made to organize tests, interfaces and classes.
The final snapshot can be found here under the spring-hello-word-cdi directory. Enjoy it!

Wednesday, December 19, 2012

A TDD approach using Spring Framework + Mockito + Lombok

Intro

This is simple Hello World Java application that successfully combines Spring Framework with Mockito and Lombok. It's just for demonstrative purposes, so the presented example is very simple and used many times before in the literature.

The final goal is to show up how simple is to combine some of the best features of each involved technology with Test-Driven-Development in mind:

  • Spring Framework: wiring
  • Mockito: isolation
  • Lombok: simplicity

Example

A text editor uses and spell checker among other things to make the life of user easier. Depending on the target language, an spell editor may change is behavior  and its dependencies as well, for example dictionaries and tokenizers. Simplifying the whole idea you may encounter a contract-driven (interface based) solution like this:

with many possible combinations of spell checkers, dictionaries and tokenizers. For example this one:
where every contract was replaced by a concrete instance. Combinations are multiple, and sometimes you cannot predict all them in a classes/interfaces design.

You want to start engaging TDD for sure, and you want to do it in a top-down fashion. That means, start testing the text editor first, then the spell checker, then the remaining pieces. You also want to do it in isolation, so spell checker and the remaining implementations aren't involved in editor tests, and it's your desire to obtain zero infrastructure code (no constructor calls). As a plus no getter nor setter nor trivial constructor implementations.

What to test?

Our test will be very simple as well, here is the top-down ordered list (remember it's a simplification of the reality):

1- Given an Editor, when a new text is pasted it should be added.
2- Given an Editor, when a new text is pasted the spell should be checked against the appended text.
3- Given an English spell checker, when a word is not found in a dictionary during the spell check then it must be signaled as misspelled and returned back.


You may be wondering, why should I test these  obvious use cases? Trust me, it's very important to cover all possible scenarios if you really want to delivery software with built-in quality. This is the hidden synergy behind TDD.


Hands on Spring Tool Suite

  1. Open STS and create a new Maven project.
  2. Check 'Create a simple project (skip archetype selection)'.
  3. Enter a Group Id = demos.sf.editor, Artifact Id = spring-hello-world and Version = 1.0.
  4. Edit your pom.xml and append all the required dependencies. It should ends like:
  5. 
      4.0.0
      demos.sf.editor
      spring-hello-word
      1.0
      Spring Framework Hello World
      Spring Framework Hello World demo w/ Unit Tests
      
        UTF-8
        3.2.0.RELEASE
      
      
        
          junit
          junit
          4.10
        
        
        
          org.springframework
          spring-test
          ${spring.version}
        
        
        
          org.springframework
          spring-beans
          ${spring.version}
        
        
        
          org.springframework
          spring-context
          ${spring.version}
        
        
          org.mockito
          mockito-all
          1.9.5
        
        
          org.projectlombok
          lombok
          0.11.6
        
      
    
    
  6. Start testing! A golden rule, don't forget it. Create a new JUnit 4 Test Case at src/test/java. Name it EditorTest in package demos.sf.editor. 
  7. Delete the existing test, called test and append a new failing test for the first use case. Its name testPasteSuccess:
  8. package demos.sf.editor;
    
    import static org.junit.Assert.fail;
    
    import org.junit.Test;
    
    public class EditorTest {
    
     @Test
     public void testPasteSuccess() {
      fail();
     }
    
    }
    
    Making the test fail it's very important, if you start failing you won't forget it until its fixed and the test pass. So the "last thing" to do is to remove the failing statement.
  9. Write the assertion first. How's that? See use case 1: "... the text should be added":
  10. ...
    import static org.junit.Assert.assertEquals;
    
    public class EditorTest {
    
     @Test
     public void testPasteSuccess() {
      String expected = "Hello everybody!";
      String actual = editor.getText();
      assertEquals(expected, actual);
      fail();
     }
    }
    The code above will fail to compile, because there isn't and variable/field called editor. This is perfectly normal in TDD, guide your design only by needs (the tests).
  11. Right-click on editor and choose "Create local variable...". Change its type from Object to Editor, a non-existing class:
  12. public class EditorTest {
    
     @Test
     public void testPasteSuccess() {
      Editor editor;
    
      String expected = "Hello everybody!";
      String actual = editor.getText();
      assertEquals(expected, actual);
      fail();
     }
    }
    
    The code above, still without compiling due to the non-existing class Editor. Right click on Editor and "Create a new class...".
  13. Annotate the Editor class for auto-implementing the getter using Lombok annotations:
  14. package demos.sf.editor;
    
    import lombok.Getter;
    
    public class Editor {
     @Getter
     private String text;
    }
    
    NOTE: Lombok must be attached to Spring Tool Suite (or Eclipse) for completion at development time. Copy your lombok.jar to STS installation folder and append the following settings to your STS.ini (eclipse.ini):
    -javaagent:/home/lago/Soft/springsource2.9.2/sts-2.9.2.RELEASE/lombok.jar
    -Xbootclasspath/a:/home/lago/Soft/springsource2.9.2/sts-2.9.2.RELEASE/lombok.jar
    
    Alternative open a terminal/command prompt and run:
    $ java -jar ~/.m2/repository/org/projectlombok/lombok/0.11.6/lombok-0.11.6.jar
    
    An install wizard gets launched. Choose your STS.ini (eclipse.ini) and press Install/Update. Finally restart your IDE.
  15. Go back to the test, and perform the call to a non-existing paste() method:
  16. public class EditorTest {
    
     @Test
     public void testPasteSuccess() {
      Editor editor;
      editor.paste("Hello everybody!");
    
      String expected = "Hello everybody!";
      String actual = editor.getText();
      assertEquals(expected, actual);
      fail();
     }
    }
    
  17. Ctrl+1 on top the editor.paste("...") call and choose "Create method paste()....". A new method is generated:
  18. public class Editor {
     @Getter
     private String text;
    
     public void paste(String cut) {
     }
    }
    
    Go back to the test, don't waste your time implementing anything at this moment, the test will drive you to that point later.
  19. In the test, the only missing thing is the editor initialization. Let's inject the Editor at test time. Convert the editor local variable to a field declaration and annotate it as @Autowired:
  20. ...
    import org.springframework.beans.factory.annotation.Autowired;
    
    public class EditorTest {
    
     @Autowired
     private Editor editor;
    
     @Test
     public void testPasteSuccess() {
      editor.paste("Hello everybody!");
    
      String expected = "Hello everybody!";
      String actual = editor.getText();
      assertEquals(expected, actual);
      fail();
     }
    }
    
  21. Create a new Spring Bean Configuration file at src/test/resources/test-applicationContext.xml and declare the editor bean on it:
  22. 
      
      
    
    
    
  23. Use the Spring test runner and load the application context via annotations:
  24. ...
    import org.junit.runner.RunWith;
    import org.springframework.test.context.ContextConfiguration;
    import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
    
    @RunWith(SpringJUnit4ClassRunner.class)
    @ContextConfiguration(locations = { "/test-applicationContext.xml" })
    public class EditorTest {
    ...
    }
    
  25. Right click on test case and Run As JUnit test. The test will fail but corner stones are ready to support more agile tests. Make the test pass by implementing the paste() method. Oops! remember to remove the fail() from the test.
    public class Editor {
     @Getter
     private String text;
    
     public void paste(String cut) {
      if(text == null) {
       text = "";
      }
      text += cut;
     }
    }
    
  26. Re-run the test, this time also using a Maven run configuration like this:
  27. mvn test
    
  28. The spring default behavior is to cache the application context between different tests in the same test case. They also introduced the annotations @TestExecutionListeners and @DirtiesContext to mark the application context as dirty after each test:
  29. ...
    import org.springframework.test.context.TestExecutionListeners;
    import org.springframework.test.context.support.DependencyInjectionTestExecutionListener;
    import org.springframework.test.context.support.DirtiesContextTestExecutionListener;
    import org.springframework.test.annotation.DirtiesContext;
    import org.springframework.test.annotation.DirtiesContext.ClassMode;
    
    @RunWith(SpringJUnit4ClassRunner.class)
    @ContextConfiguration(locations = { "/test-applicationContext.xml" })
    @TestExecutionListeners({ DependencyInjectionTestExecutionListener.class,
     DirtiesContextTestExecutionListener.class })
    @DirtiesContext(classMode = ClassMode.AFTER_EACH_TEST_METHOD)
    public class EditorTest {
    ...
    }
    
  30. Now starts the use case 2. First append the test in failing mode:
  31. ...
    public class EditorTest {
     ...
     @Test
     public void testAddParagraphSpellIsChecked() {
      fail();
     }
    }
    
  32. Using Mockito style, we need to verify that the spell is checked against the pasted text. The syntax is straightforward it means that check() method must be called only once with "Hello everybody!":
  33. ...
    import static org.mockito.Mockito.only;
    import static org.mockito.Mockito.verify;
    
    @RunWith(SpringJUnit4ClassRunner.class)
    @ContextConfiguration(locations = { "/test-applicationContext.xml" })
    @TestExecutionListeners({ DependencyInjectionTestExecutionListener.class,
      DirtiesContextTestExecutionListener.class })
    @DirtiesContext(classMode = ClassMode.AFTER_EACH_TEST_METHOD)
    public class EditorTest {
    
     ...
    
     @Autowired
     private SpellChecker spellChecker;
    
     @Test
     public void testAddParagraphSpellIsChecked() {
      editor.paste("Hello everybody!");
      verify(spellChecker, only()).check("Hello everybody!");
      fail();
     }
    }
    
  34. At this time we need to create a new SpellChecker interface:
  35. package demos.sf.editor;
    
    public interface SpellChecker {
    
     void check(String text);
    
    }
    
  36. The next step is to provide an spell checker mock to the application context:
  37. 
      
      
      
        
      
    
    
  38. Remove the fail() from the test and run all tests and you will get a test failure saying: 'Wanted but no invoked: spellChecker.check("Hello everybody!")'. That makes sense since we are not invoking the SpellChecker.check() from Editor.paste(). In fact haven't create any kind of dependency Editor -> SpellChecker. Let's do it at class level and force its injection at construction time using Lombok's @RequiredArgsConstructor:
  39. package demos.sf.editor;
    
    import lombok.Getter;
    import lombok.RequiredArgsConstructor;
    
    @RequiredArgsConstructor
    public class Editor {
     @Getter
     private String text;
    
     private final SpellChecker spellChecker;
    
     public void paste(String cut) {
      if (text == null) {
       text = "";
      }
      text += cut;
     }
    }
    
  40. Declare the constructor injection in the application context as well and re-run the tests:
  41. 
      
        
      
      
        
      
    
    
  42. Oops! The same failure: 'Wanted but no invoked: spellChecker.check("Hello everybody!")'. Implement the SpellChecker.check() call and run the tests again:
  43. package demos.sf.editor;
    
    import lombok.Getter;
    import lombok.RequiredArgsConstructor;
    
    @RequiredArgsConstructor
    public class Editor {
     @Getter
     private String text;
    
     private final SpellChecker spellChecker;
    
     public void paste(String cut) {
      if (text == null) {
       text = "";
      }
      text += cut;
      spellChecker.check(cut);
     }
    }
    
    All tests should now pass:

Final Snapshot

  • The test case at : src/test/java/demos/sf/editor/EditorTest.java:
  • package demos.sf.editor;
    
    import static org.junit.Assert.assertEquals;
    import static org.mockito.Mockito.only;
    import static org.mockito.Mockito.verify;
    
    import org.junit.Test;
    import org.junit.runner.RunWith;
    import org.springframework.beans.factory.annotation.Autowired;
    import org.springframework.test.annotation.DirtiesContext;
    import org.springframework.test.annotation.DirtiesContext.ClassMode;
    import org.springframework.test.context.ContextConfiguration;
    import org.springframework.test.context.TestExecutionListeners;
    import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
    import org.springframework.test.context.support.DependencyInjectionTestExecutionListener;
    import org.springframework.test.context.support.DirtiesContextTestExecutionListener;
    
    @RunWith(SpringJUnit4ClassRunner.class)
    @ContextConfiguration(locations = { "/test-applicationContext.xml" })
    @TestExecutionListeners({ DependencyInjectionTestExecutionListener.class,
      DirtiesContextTestExecutionListener.class })
    @DirtiesContext(classMode = ClassMode.AFTER_EACH_TEST_METHOD)
    public class EditorTest {
    
     @Autowired
     private Editor editor;
    
     @Autowired
     private SpellChecker spellChecker;
    
     @Test
     public void testPasteSuccess() {
      editor.paste("Hello everybody!");
    
      String expected = "Hello everybody!";
      String actual = editor.getText();
      assertEquals(expected, actual);
     }
    
     @Test
     public void testAddParagraphSpellIsChecked() {
      editor.paste("Hello everybody!");
      verify(spellChecker, only()).check("Hello everybody!");
     }
    }
    
  • The test case at : src/main/java/demos/sf/editor/Editor.java:
  • package demos.sf.editor;
    
    import lombok.Getter;
    import lombok.RequiredArgsConstructor;
    
    @RequiredArgsConstructor
    public class Editor {
     @Getter
     private String text;
    
     private final SpellChecker spellChecker;
    
     public void paste(String cut) {
      if (text == null) {
       text = "";
      }
      text += cut;
      spellChecker.check(cut);
     }
    }
    
  • The test case at : src/main/java/demos/sf/editor/SpellChecker.java:
  • package demos.sf.editor;
    
    public interface SpellChecker {
    
     void check(String text);
    
    }
    
  • The test case at : src/main/resources/test-applicationContext.xml:
  • 
      
        
      
      
        
      
    
    
You can obtain the source code from here. Enjoy it!